Pádraig Brady <[email protected]> writes:
> First of all thanks for looking into this.
> It does look useful. Defense in depth and all that.
>
> From a high level it seems useful to mark each utility
> with the privileges it requires, but we need to be quite
> conservative I think. Users can externally compose
> extra restrictions on top after all.
True. I guess there is 'setpriv' from util-linux [1]. That allows the
use of Landlock, at least. Finding out which rules should be used,
though, seems like a choice that isn't most efficiently made by the end
user.
> E.g. restricting exec() and network access seems useful to many utilities.
> (Though I see landlock doesn't currently restrict UDP access).
It actually does support restricting UDP access. If you have a recently
updated Fedora system, for example:
$ uname -sr
Linux 7.2.10-200.fc44.x86_64
$ grep '^#define.*_UDP' /usr/include/linux/landlock.h
#define LANDLOCK_ACCESS_NET_BIND_UDP (1ULL << 2)
#define LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP (1ULL << 3)
It was introduced in ABI 10. I assume you were looking at the man-pages
where they are not documented yet.
I was going to document them, but I see there is a patch that appears to
be waiting for review [2].
> Also since reduced privileges inherit, you couldn't apply any to
> `split --filter` for example, since that should be allowed to run anything.
Yes, I forgot to mention that limitation.
> Even ls (and others) need access to the net for NSS dependencies.
> Then cksum openssl dependencies have extensive system interactions,
> which would limit what restrictions they might impose.
True.
> Then there are setups like fakeroot, which intercepts calls
> redirecting them (over net/ipc) to fakerootd, so a landlock
> setup that restricted network would break that.
> Also user space auditing solutions come to mind as
> something that might be negatively restricted.
Ah, thanks for those details. I was not aware that fakeroot could
operate over TCP connections.
> In summary the generality of coreutils usage
> works against being able to impose restrictions.
Yes, sadly. My understanding is that Debian makes extensive use of
'fakeroot'. Let's not give them a rude surprise by breaking it. :)
> It needs to be very carefully considered at least.
Agreed, thanks for your input.
Collin
[1] https://man7.org/linux/man-pages/man1/setpriv.1.html
[2] https://lore.kernel.org/linux-man/[email protected]/
