On Thu, Mar 03, 2022 at 08:10:26PM -0500, JT wrote:
> I replied this morning saying I'd be willing to help run the ball on this,
> but this seems like the sort of thing that needs some coordinated planning
> for what Fedora as a distro wants the goals to be. I'm waiting to Matthew
> to chime back
Am 03.03.22 um 16:04 schrieb Rahul Sundaram:
What I would suggest here is we make it easier to adopt the opt out
model by explicitly setting services to opt out for things they can't
handle, ie)
Honestly, I expected more of a wake-up-call to those service-maintainers
(upstream/downstream)
On Thu, Feb 24, 2022 at 7:14 PM Zbigniew Jędrzejewski-Szmek
wrote:
> systemd-analyze security shows whether units use systemd hardening
> features. Those units may well use other features, and may well be
> very secure.
My vague recollection from running systemd-analyze security
from some time
On Thu, Mar 3, 2022 at 8:01 PM Rahul Sundaram wrote:
> Hi
>
> On Wed, Mar 2, 2022 at 11:40 AM Matthew Miller wrote:
>
>> On Thu, Feb 24, 2022 at 08:13:15PM +0100, Zbigniew Jędrzejewski-Szmek
>> wrote:
>> > It would probably be good to use more of those features, but you need
>> > to understand
Hi
On Wed, Mar 2, 2022 at 11:40 AM Matthew Miller wrote:
> On Thu, Feb 24, 2022 at 08:13:15PM +0100, Zbigniew Jędrzejewski-Szmek
> wrote:
> > It would probably be good to use more of those features, but you need
> > to understand the service very well to know what systemd security
> > features
Hi
On Thu, Mar 3, 2022 at 5:07 PM Lennart Poettering wrote:
>
> There have been various requests of generalizing this, and making it
> available for any kind of service, not just portable services. I'd be
> onboard with that actually, but there are some unanswered questions
> regarding how
On Do, 03.03.22 10:04, Rahul Sundaram (methe...@gmail.com) wrote:
> > ProtectHome= for example implies that a separate mount namespace is
> > allocated for each service. if you enable that for *all* services at
> > once, then this means all services will suddenly live in their own
> > mount
On Thu, Mar 03, 2022 at 03:51:19PM +0100, Lennart Poettering wrote:
> Adding security into a system that didn't have it but is widely
> deployed and developed for is *hard*. It makes opt-out security really
> hard to do, which is why we went for opt-in. Tools like
> "systemd-analyze security"
Hi
On Thu, Mar 3, 2022 at 9:51 AM Lennart Poettering wrote:
>
> Yes, opt-out would be better than opt-in, but it would be a major
> compat break, UNIX software doesn't expect to be sandboxed, so if you
> sandbox everything out-of-the-box you'll be drowning in bugs, and the
> failure modes are
On Do, 03.03.22 09:25, Rahul Sundaram (methe...@gmail.com) wrote:
> Hi
>
> On Thu, Mar 3, 2022 at 8:18 AM Zbigniew Jędrzejewski-Szmek wrote
>
> >
> > What do you mean by "global service overrides"?
>
> Currently security hardening features are opt-in. You will have to set it
> on a per service
Hi
On Thu, Mar 3, 2022 at 8:18 AM Zbigniew Jędrzejewski-Szmek wrote
>
> What do you mean by "global service overrides"?
Currently security hardening features are opt-in. You will have to set it
on a per service level. What I would prefer to see is the ability to have
an opt out of hardening
With the obvious understanding that all work is done by people who are
willing to pitch in... who's domain does this fall under? Would this be
something that the Fedora Security Team would focus on? Would this be done
by the maintainers of the individual 'services'. I realize a lot of what
On Thu, Mar 3, 2022 at 8:24 AM Lennart Poettering
wrote:
>
> badly. One good example for that is crond: you never know what cron
> jobs intend to do, hence you cannot sandbox crond as a whole
> reasonably. Moreover, runtime matters: short-lived stuff is much less
>
>
I've also run into another
On Do, 24.02.22 16:29, Marius Schwarz (fedora...@cloud-foo.de) wrote:
> Do those "insecure" units come from upstream projects, or is Fedora lagging
> behind some patches?
"insecure" is misleading. We call it "exposed", which is a different
thing.
> Is there a way to find out, if missing
On Wed, Mar 02, 2022 at 04:23:00PM -0500, Rahul Sundaram wrote:
> Hi
>
> On Wed, Mar 2, 2022 at 12:31 PM Zbigniew Jędrzejewski-Szmek wrote:
>
> > On Thu, Feb 24, 2022 at 02:28:56PM -0500, Rahul Sundaram wrote:
> > > Ability to modify these policies via configuration (the above one looks
> > >
Hi
On Wed, Mar 2, 2022 at 12:31 PM Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 24, 2022 at 02:28:56PM -0500, Rahul Sundaram wrote:
> > Ability to modify these policies via configuration (the above one looks
> > like a build config) and ability to do global overrides and set the
> >
On Thu, Feb 24, 2022 at 02:28:56PM -0500, Rahul Sundaram wrote:
> Hi
>
> On Thu, Feb 24, 2022 at 2:14 PM Zbigniew Jędrzejewski-Szmek
>
> >
> > Systemd 250 (coming in F36), has --security-policy switch which can be
> > used to enable/disable some of the checks. There is no way to tell
> >
On Thu, Feb 24, 2022 at 08:13:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> It would probably be good to use more of those features, but you need
> to understand the service very well to know what systemd security
> features can be enabled for it.
I'd definitely love to see us put more effort
Hi
On Thu, Feb 24, 2022 at 2:14 PM Zbigniew Jędrzejewski-Szmek
>
> Systemd 250 (coming in F36), has --security-policy switch which can be
> used to enable/disable some of the checks. There is no way to tell
> systemd-analyze that things about a specific unit though.
>
Ability to modify these
On Thu, Feb 24, 2022 at 04:29:27PM +0100, Marius Schwarz wrote:
> Hi Guys,
>
> running a hardening tool I stumpled about systemd own security analysis,
systemd-analyze security shows whether units use systemd hardening
features. Those units may well use other features, and may well be
very
Hi Guys,
running a hardening tool I stumpled about systemd own security analysis,
which doesn't look good:
$ systemd-analyze security
UNIT EXPOSURE PREDICATE HAPPY
NetworkManager.service 7.8 EXPOSED
21 matches
Mail list logo
