Re: systrace(4) policies in pkgsrc

[Christian Biere <christianbiere%gmx.de@localhost>]

Blair Sadewitz wrote:
> Does anyone have any ideas on how systrace policies for packages could
> be implemented in pkgsrc?

I think piggy-packing this on pkgsrc is not a good idea. Even if all
platforms had systrace, programs will usually behave different on
each, for example, due to different implementations, different hierarchy
conventions. The latter already differs heavily between different machines
or users. Such an effort would be worth an own self-standing project
something which could then maybe be installed through pkgsrc. Also,
when you're updating your system, syscalls frequently change. There
may be new syscalls or the implementation of some library function
changed and requires different rules.

> I got this idea tonight while setting up GNOME, as there are daemons
> that must run as root which make me nervous.  Moreover, audio servers
> such as jackd and other things which need to change their execution
> priorities could be wrapped with systrace as well.

Well, I don't use GNOME or any other desktop environment but it's questionable
whether they really need those privileges. Sometimes authors think mlock()
absolutely requires root-privileges albeit that's only the case on Linux. On
other systems you can configure a memory limit for each user that may be
locked. Likewise, other resources often don't require privileges either and
certainly not root-privileges. You can often do miracles with file descriptor
passing.

Actually, I have never used systrace for privilege elevation because it's
awkward to set up. I only use it to tie down programs. Also, this often
cripples programs which is acceptable for me but might not be for the
average user. However, if you're too gracious with what you permit, systrace
can easily become pointless. Further, if you don't trust the original
software authors to write secure software, why would you trust maintainers
of such systrace rules to do the right thing? I really think the rules
have to created by the site itself because only the site knows how much
crippling is acceptable and what they consider a threat.

I mean you could simply try it yourself for a not-so-complex package to
create policies that will work with FreeBSD, OpenBSD and NetBSD for each
of their maintained versions. Then ask yourself whether you think it's
maintainable. That said, I could imagine it might be worth the effort for
few critical and potentially very dangerous packages.
 
-- 
Christian