
IP Accounting and Access Lists with Systemd - JoshTriplett
http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html
======
jlgaddis
Many moons ago, support for TCP wrappers was removed from systemd -- and, a
bit later, OpenSSH, IIRC. Fine, I understand. Personally, I still like tcpd
(it's an extra layer) and I still use it... but I realize that not very many
others do. Okay, I can live with this decision.

Then, about two weeks ago, Red Hat decides they're gonna deprecate TCP
wrappers, with a Red Hat employee saying:

> _TCP wrappers is a simple tool to block incoming connection on application
> level. This was very useful 20 years ago, when there were no firewalls in
> Linux. This is not the case for today and connection filtering should be
> done in network level or completely in application scope if it makes sense._

Okay, fine. I still think it's useful as an extra layer but, nobody really
uses it so, sure, let's get rid of it. I'm on board.

Now, all of a sudden, this functionality shows up in systemd (announced
yesterday)?

Really!? This is (one of the) reason(s) why some of us greybeards loathe
systemd (and just when I was starting to become "okay" with it, too).

~~~
poettering
> Really!? This is (one of the) reason(s) why some of us greybeards loathe
> systemd (and just when I was starting to become "okay" with it, too).

I am not sure why you imply that there was some evil scheme behind all this.
In reality, things are a bit different: one group at Red Hat decided to put an
end to TCP wrappers (which btw is something other distros already did a while
back, we are late at the party), and another group then offered to make a more
modern replacement available, that could cover some of the uses, in order not
leave users in the cold. I am not sure why you think that's an evil thing to
do? Isn't it nicer to drop something with a suggestion how to replace it then
to drop it without replacement?

Also, let's not forget: this functionality is implemented in the kernel,
systemd merely adds knobs to expose this kernel functionality to the user.
Hence, no, this functionality didn't really "show up in systemd". It showed up
in the kernel, and systemd just wraps it to make it usable.

I mean, this is a dilemma, isn't it? Whatever we do you are unhappy, right?
;-)

Lennart

~~~
reacweb
I do not think he is unhappy about this feature in systemd. He complains about
the process and communication: removing a feature arguing it is useless then
providing a replacement.

Personally, I am very pleased with systemd and thanks to its novelty, it puts
me on a same level as all the "greybeards". Continue the good work and please,
take special care of the man pages.

------
jcrites
Another great sandboxing capability added to systemd, and as easily employed
as a single flag:

    
    
      IPAddressDeny=any
    

What I enjoy about systemd is the fact that I can employ capabilities like
this with any process on the system using only a line of configuration. FTA:

> It's a simple way to lock down distribution/vendor supplied system services
> by default. For example, if you ship a service that you know never needs to
> access the network, then simply set IPAddressDeny=any (possibly combined
> with IPAddressAllow=localhost) for it, and it will live in a very tight
> networking sand-box it cannot escape from. systemd itself makes use of this
> for a number of its services by default now. For example, the logging
> service systemd-journald.service, the login manager systemd-logind or the
> core-dump processing unit systemd-coredump@.service all have such a rule set
> out-of-the-box, because we know that neither of these services should be
> able to access the network, under any circumstances.

~~~
Tharre
If you want to use this for sandboxing, it may be a good idea to also include

    
    
      RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
    

to block non-IP sockets.

------
alphaalpha101
Another systemd release, another bloating of the attack surface of the now-
standard init system.

I'm sure this is useful but init is absolutely the wrong place for it.

------
sandGorgon
What is the general direction of packet filtering in Linux - it seems that it
is nftables vs ebpf/XDP at this point. In fact
[https://lwn.net/Articles/609571/](https://lwn.net/Articles/609571/)

> _There was "a brawl" at the workshop about possibly replacing the nftables
> virtual machine with eBPF, but there is one major show-stopper in any such
> plan: nftables allows partial replacement of a firewall configuration, while
> eBPF, in its current form, would not. _

Cloudflare, Netflix, Facebook, etc are all using eBPF via XDP
[https://www.iovisor.org/technology/ebpf](https://www.iovisor.org/technology/ebpf)

eBPF and XDP are supported seamlessly on kernel 4.12 and later.

------
XorNot
This is really nice. It'd be nice to see port/protocol filtering included in
this functionality some time in the future as well since it would fit the
theme of sandboxing around processes - i.e. start a daemon up and have the
kernel enforce which ports inbound/outbound can be accessed. This is something
Docker accidentally provides that's fairly useful.

------
freedomben
The clarity and depth that Lennart writes with is always impressive to me.
Another highly educational post from a master.

------
throwme211345
Fuck this. freebsd is now the way forward. Linux has been compromised and in a
way that is understandable to anyone conversant with the design philosophy of
the underlying userspace tools.

------
mdimec4
What does the init system have to do with this?

~~~
askz
It is useful for sandboxing processes

~~~
e12e
One can certainly make that argument. But now you have two ways to run
executables; via the shell / fork - and through the init system (with various
capabilities etc).

I guess I'd prefer a single api, so I could sandbox (or not) netcat and
Firefox the same way as samba and openssh.

It might not be a _major_ point - but it would be nice if there was a single
way to "run in env/with configuration" that didn't involve an extra (and
somewhat opinionated and opaque) wrapper.

It's a little like the dot.desktop-file approach to dress up cli
tools/interfaces in a desktop gui - it's brittle and doesn't really work all
that well. And the cross-platform story isn't great.

On the other hand: attaching capabilities to process trees seems better that
text-based matching etc. I suppose I think the bsd jail approach looks better
- even though that to involves a "wrapper" \- but it's a wrapper that's not
artificially limited to "services".

[ed: the fact that any kind of name lookup is left out is also a bit odd - as
demonstrated by the curl example, for many uses of whitelisting name
resolution is essential. And for ldap/kerberos/ad being able to work with
named resources seems to be the only sane idea. That's why we use dns and
catalog services in the first place! This even more clear in an ipv6
environment, as the addresses are generally longer, and auto-assignment is
somewhat better than ipv6/DHCP.]

------
bluetech
systemd should have a "whitelist" mode, where everything is locked down by
default. Or at least, some /usr/share/doc/systemd/locked-down-example.service
file with all of the relevant options set to "secure mode". It can be hard to
follow all of the new features :)

