On 12/13/2016 03:21 PM, Tom Hughes wrote:
> On 13/12/16 20:02, Przemek Klosowski wrote:
>> On 12/13/2016 02:51 PM, Lennart Poettering wrote:
>>> Yeah, this is really what it boils down to: the goal with the systemd
>>> directives is to make things easy to grok and easy to change. I can
>>>
On Wed, 14 Dec 2016, Scott Schmit wrote:
IPsec requires AF_NETLINK (NETLINK_XFRM) to manage the security
associations & security policies. libreswan probably also needs to be
able to manage the routing for IPsec tunnels (NETLINK_ROUTE[6]).
The nature of libreswan is that it allows custom
On Wed, Dec 14, 2016 at 10:08:33AM +0100, Florian Weimer wrote:
> > The original RFCs for IPv6 mandated support for IPsec, but that's no
> > longer required as of RFC 6434. Nothing else popped out at me as
> > necessary for IPv6, but it's probably a moot point given XFRM.
>
> IPv6 people argue
On 12/14/2016 07:44 AM, Scott Schmit wrote:
On Tue, Dec 13, 2016 at 05:54:54PM +0100, Florian Weimer wrote:
On 12/13/2016 12:17 PM, Lennart Poettering wrote:
On Mon, 12.12.16 21:22, Paul Wouters (p...@nohats.ca) wrote:
For us (libreswan) it probably makes less sense to restrict address
family
On Tue, Dec 13, 2016 at 05:54:54PM +0100, Florian Weimer wrote:
> On 12/13/2016 12:17 PM, Lennart Poettering wrote:
> > On Mon, 12.12.16 21:22, Paul Wouters (p...@nohats.ca) wrote:
> > > For us (libreswan) it probably makes less sense to restrict address
> > > family in the daemon. Our daemon just
Hi
On Tue, Dec 13, 2016 at 12:00 PM Lennart Poettering
> Well, some of them are pretty drastic. For example, I think it would
> make a ton of sense to run all daemons where that's possible with
> ProtectSystem=strict. This would make the entire directory tree
> read-only for them (with the
On Tue, Dec 13, 2016 at 09:10:46PM +0100, Lennart Poettering wrote:
> On Tue, 13.12.16 15:02, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
>
> > On 12/13/2016 02:51 PM, Lennart Poettering wrote:
> > > Yeah, this is really what it boils down to: the goal with the systemd
> > > directives
On 13/12/16 20:02, Przemek Klosowski wrote:
On 12/13/2016 02:51 PM, Lennart Poettering wrote:
Yeah, this is really what it boils down to: the goal with the systemd
directives is to make things easy to grok and easy to change. I can
probably explain to most Linux admins who have administered a
On Tue, 13.12.16 15:02, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
> On 12/13/2016 02:51 PM, Lennart Poettering wrote:
> > Yeah, this is really what it boils down to: the goal with the systemd
> > directives is to make things easy to grok and easy to change. I can
> > probably explain
On 12/13/2016 02:51 PM, Lennart Poettering wrote:
Yeah, this is really what it boils down to: the goal with the systemd
directives is to make things easy to grok and easy to change. I can
probably explain to most Linux admins who have administered a current
Fedora in 5min what
On Tue, 13.12.16 14:25, Matthew Miller (mat...@fedoraproject.org) wrote:
> On Tue, Dec 13, 2016 at 10:42:08AM -0800, Japheth Cleaver wrote:
> > >For a less-effort version, we could update
> > >https://fedoraproject.org/wiki/Packaging:Systemd and have an (internal)
> > >marketing campaign asking
On Tue, Dec 13, 2016 at 10:42:08AM -0800, Japheth Cleaver wrote:
> >For a less-effort version, we could update
> >https://fedoraproject.org/wiki/Packaging:Systemd and have an (internal)
> >marketing campaign asking people to update their packages (as
> >suggested, ideally upstream).
>
> I'd much
On 12/13/2016 7:00 AM, Matthew Miller wrote:
On Tue, Dec 13, 2016 at 12:14:44PM +0100, Lennart Poettering wrote:
Well, the security policies need to be adapted to the service in
question, hence a blanket switch to enable all of them for every
service is problematic. Let's say you block
On Tue, 13.12.16 10:00, Matthew Miller (mat...@fedoraproject.org) wrote:
> On Tue, Dec 13, 2016 at 12:14:44PM +0100, Lennart Poettering wrote:
> > Well, the security policies need to be adapted to the service in
> > question, hence a blanket switch to enable all of them for every
> > service is
On 12/13/2016 12:17 PM, Lennart Poettering wrote:
On Mon, 12.12.16 21:22, Paul Wouters (p...@nohats.ca) wrote:
that's totally possible, and can be functionality-wise entirely
equivalent. The only difference is: systemd makes all of this
trivially easy to use, by making this a single-line
On Tue, 13.12.16 10:52, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
> On 12/12/2016 04:02 PM, Lennart Poettering wrote:
> > Hmm, yeah, I should probably blog more about all the nice sandboxing
> > features we have now in systemd. There's quite some stuff now we
> > should enable
On Tue, Dec 13, 2016 at 03:49:45PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > For a less-effort version, we could update
> > https://fedoraproject.org/wiki/Packaging:Systemd and have an (internal)
> > marketing campaign asking people to update their packages (as
> > suggested, ideally
On 12/12/2016 04:02 PM, Lennart Poettering wrote:
Hmm, yeah, I should probably blog more about all the nice sandboxing
features we have now in systemd. There's quite some stuff now we
should enable wherever we can. Specifically ProtectSystem=,
ProtectHome=, ProtectKernelTunables=,
On Tue, Dec 13, 2016 at 10:00:10AM -0500, Matthew Miller wrote:
> On Tue, Dec 13, 2016 at 12:14:44PM +0100, Lennart Poettering wrote:
> > Well, the security policies need to be adapted to the service in
> > question, hence a blanket switch to enable all of them for every
> > service is
On Tue, Dec 13, 2016 at 12:14:44PM +0100, Lennart Poettering wrote:
> Well, the security policies need to be adapted to the service in
> question, hence a blanket switch to enable all of them for every
> service is problematic. Let's say you block gettimeofday()
> system-wide, but then run an NTP
On Mon, 12.12.16 21:22, Paul Wouters (p...@nohats.ca) wrote:
> > that's totally possible, and can be functionality-wise entirely
> > equivalent. The only difference is: systemd makes all of this
> > trivially easy to use, by making this a single-line change in a unit
> > file without involving C
On Tue, 13.12.16 01:56, Rahul Sundaram (methe...@gmail.com) wrote:
> Hi
>
> On Mon, Dec 12, 2016 at 4:03 PM Lennart Poettering
> > Hmm, yeah, I should probably blog more about all the nice sandboxing
>
> > features we have now in systemd.
>
>
> It would be useful if we can set these type of
On Mon, 12 Dec 2016, Lennart Poettering wrote:
Note that I wonder if restricting address families really belongs in
systemd. Why isnt this a libcap-ng capability? That way my software
can support this without depending on systemd.
hu?
libcap-ng is a library to manage Linux process
Hi
On Mon, Dec 12, 2016 at 4:03 PM Lennart Poettering
> Hmm, yeah, I should probably blog more about all the nice sandboxing
> features we have now in systemd.
It would be useful if we can set these type of options as system wide - for
both the distribution/vendor and for admin overrides with
On Mon, 12.12.16 13:14, Matthew Miller (mat...@fedoraproject.org) wrote:
> Question 2: What about *other* systemd security features? The blog post
> mentions restricting namespaces as an upcoming feature, and there are
> other existing ones which we are not using systemically — like
> PrivateTmp,
On Mon, 12.12.16 14:41, Paul Wouters (p...@nohats.ca) wrote:
> Note that I wonder if restricting address families really belongs in
> systemd. Why isnt this a libcap-ng capability? That way my software
> can support this without depending on systemd.
hu?
libcap-ng is a library to manage Linux
On Mon, Dec 12, 2016 at 01:14:27PM -0500, Matthew Miller wrote:
> In case you haven't seen: there was a recent kernel vulnerability in a
> feature called "AF_PACKET". Most services don't need to use the raw
> sockets this makes available, and on his blog*, Lennart Poettering notes
> that systemd
On Mon, 12 Dec 2016, Matthew Miller wrote:
Question 1: How can we take advantage of this feature in specific? We
could bulk file a bunch of bugs. Or, what about turning on some more
restrictive defaults (AF_INET AF_INET6 AF_UNIX) on some flag day in
Rawhide, and having services which have
In case you haven't seen: there was a recent kernel vulnerability in a
feature called "AF_PACKET". Most services don't need to use the raw
sockets this makes available, and on his blog*, Lennart Poettering notes
that systemd actually has a feature where services can whitelist or
blacklist address
29 matches
Mail list logo
