Re: systrace(4) policies in pkgsrc

["Blair Sadewitz" <blair.sadewitz%gmail.com@localhost>]

On 11/14/06, Christian Biere <christianbiere%gmx.de@localhost> wrote:
> 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.

It's true that this sort of thing could be subsumed into a project
which uses many methods to secure pkgsrc, systrace being only one of
them.
However, given pkgsrc's special relationship with NetBSD, it seems to
me that it might be worth it to make this a NetBSD-only effort, at
least for the imaginary forseeable future of this hypothetical
project.


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.

This is a good point, though I'm not sure if it would make such an
effort pointless.  At the very least, would it make sense to strive to
support this for some packages in pkgsrc release branches for, let's
say, the latest NetBSD release?  Perhaps something to do when 4.0
comes out?



> 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.
Well, AFAIK BSD has no mechanism for anything like "real-time" (I use
the quotation marks because I know that what I'm talking about isn't
actually real-time at all) priority without the program running as
root.

> 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.

I am aware of this problem, and I can't claim that I'm capable of
designing perfect systrace policies; I've heard Theo de Raadt say that
he's NEVER seen a properly implemented systrace policy, but then
again, ideals are never real, that's why they're ideal (yay,
metaphysics).  However, if this is placed in the options framework, at
least a cautionary note could be provided not to turn this on unless
you're willing to deal with its [side] effects.


> 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?

Because there is a lot of moribund software out there still in use for
which security will never be much of a concern.  IMHO, one step closer
to perfection is better than not taking any steps at all, provided
functionality is maintained.  Am I wrong here?

> 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.

Perhaps, then, the site administrator(s) could customize the included
policies for an optimal balance of functionality vs. security.
Templates are often better than nothing, IMHO.

> 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.

As I've said, I think this should be a NetBSD-only effort, unless
there're folks wishing to take on the task for other platforms.



Then ask yourself whether you think it's
> maintainable.

I did ask myself, and I could not conclude either way without asking
others, so I made my initial post. ;)

That said, I could imagine it might be worth the effort for
> few critical and potentially very dangerous packages.

The fact that it's probably worthwhile for a few packages seems to
suggest placement of systrace policies in the options framework, no?


Warm regards,

--Blair


--
Support WFMU-FM: free-form radio for the masses!

<http://www.wfmu.org/>
91.1 FM Jersey City, NJ
90.1 FM Mt. Hope, NY

"The Reggae Schoolroom":
<http://www.wfmu.org/playlists/RS/>