Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Colin Watson]

On Fri, Dec 01, 2017 at 12:05:20PM +0100, Andrew Shadura wrote:
> How about https://notabug.org/rain1/linux-seccomp-pledge/?

Promising enough idea, but it looks like the author gave up on it and
never finished the job.  This sort of thing is only really helpful if
it's maintained by somebody who's putting more work into keeping it
complete and current than I want to put into doing a small part of the
job. :-)

-- 
Colin Watson   [cjwat...@debian.org]

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Colin Watson]

On Thu, Nov 30, 2017 at 07:18:43PM -0800, Seth Arnold wrote:
> On Fri, Dec 01, 2017 at 01:29:44AM +, Colin Watson wrote:
> > but should be much easier to maintain, and would probably also make it
> > easier to switch to a syscall-set-confining library if such a thing
> > exists in the future.
> 
> Would a version of OpenBSD's pledge() system call have looked appealing to
> you, if it were implemented as a library interface around seccomp? There's
> already roughly two dozen categories, though not all may translate well to
> seccomp's abilities.
> 
> https://man.openbsd.org/pledge.2

Something like that, yes; maybe something like "stdio rpath flock proc
exec" in man-db's case, although I'm sure that would need some tweaking.

It's nice to be able to say "these sets, plus this handful of additional
syscalls", which pledge can't do.

Also, I'm very glad that seccomp persists across execve(2); I much
prefer this to the pledge model.

-- 
Colin Watson   [cjwat...@debian.org]

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Seth Arnold]

On Fri, Dec 01, 2017 at 01:29:44AM +, Colin Watson wrote:
> but should be much easier to maintain, and would probably also make it
> easier to switch to a syscall-set-confining library if such a thing
> exists in the future.

Would a version of OpenBSD's pledge() system call have looked appealing to
you, if it were implemented as a library interface around seccomp? There's
already roughly two dozen categories, though not all may translate well to
seccomp's abilities.

https://man.openbsd.org/pledge.2

Thanks


signature.asc
Description: PGP signature

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Colin Watson]

On Fri, Dec 01, 2017 at 12:35:06AM +, Colin Watson wrote:
> (Hmm, though maybe a reasonable stopgap would be to copy the relevant
> syscall lists from systemd's code.  That would leave me updating things
> manually from time to time, which isn't great, but it would probably
> still be better than maintaining my own list!  I think I'll do this.)

That was indeed a worthwhile exercise.  I'm now down to five sets taken
verbatim from systemd, which are long but I can just update them
wholesale from time to time; three sets from systemd from which I've
extracted subsets, e.g. a read-only subset of file system operations;
and nine additional syscalls, some of which I still need to review and
possibly either restrict by arguments or drop.  Those are much more
tolerable numbers than a monolithic block of over a hundred syscalls.

The exercise caused me to notice several syscalls I'd missed, and some
that I'd included inappropriately.  It's still a lot of lines of code,
but should be much easier to maintain, and would probably also make it
easier to switch to a syscall-set-confining library if such a thing
exists in the future.

(Side note: this strategy works partly because man-db is under a licence
that the relevant file in systemd can be converted to using LGPL2.1
section 3.  If that weren't the case then it would at the very least be
much less obvious that this is a permissible thing to do.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Colin Watson]

On Wed, Nov 29, 2017 at 05:36:30PM -0800, Russ Allbery wrote:
> Vincas Dargis  writes:
> > Since mentioned, I would like that these daemons would implement seccomp
> > filtering themselves, meaning like within application itself, using
> > libeseccomp. Thy can fine-grain what thread what syscalls can make.
[...]
> Does libeseccomp now have maintained system call classes similar to
> systemd?

(I think "libeseccomp" was a typo for "libseccomp".  I wouldn't normally
bother to point this out, but you reproduced it, and it caused me to
briefly get excited at the idea that maybe there was an "extended
seccomp" library or something.)

As far as I can tell, no.  I've been working on applying seccomp
confinement to parts of man-db recently (there are plenty of bits of its
code that could usefully be hardened against the admittedly small chance
of a compromise via crafted manual page text).  I have the self-imposed
spec of "should allow the process to do most reasonable things to
itself, to read and write data from and to already-open file
descriptors, to open files in read-only mode, and to fork new processes
with the same restrictions".  This results in a list of 116 syscalls at
last count, and it's hard to be certain that such a list is complete.
Since this is in application code rather than service code, systemd's
SystemCallFilter predefined sets aren't directly usable in this context;
I'd definitely like to use a library that provided something similar,
maybe a wrapper on top of libseccomp.

(Hmm, though maybe a reasonable stopgap would be to copy the relevant
syscall lists from systemd's code.  That would leave me updating things
manually from time to time, which isn't great, but it would probably
still be better than maintaining my own list!  I think I'll do this.)

-- 
Colin Watson   [cjwat...@debian.org]

seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

[Russ Allbery]

Vincas Dargis  writes:

> Since mentioned, I would like that these daemons would implement seccomp
> filtering themselves, meaning like within application itself, using
> libeseccomp. Thy can fine-grain what thread what syscalls can make.

Yes, this is potentially even better.  But there are cases where we can
apply filters that upstream may not be able to assume for various reasons,
and a lot of upstreams who won't be willing to take Linux-specific code
inside the daemon itself.

But this would be fantastic for things like ImageMagick, which are
otherwise a notorious source of RCEs.

Does libeseccomp now have maintained system call classes similar to
systemd?  If we could build a tool that could apply namespace and filter
rules using system call classes like that, it would make it easy to
support similar hardening in sysvinit as well.  Last time I looked at the
various stand-alone jailing utilities like firejail, they seemed to be
missing the nice system call groupings that let you not have to know
exactly what system calls result from standard IO operations, but
hopefully someone has since tackled this.

-- 
Russ Allbery (r...@debian.org)