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

If people upgrade from 3.x to 4.x without scrapping everything - which
I believe is the normal way, their installed libraries may use some
old compatibility syscalls. You coukd write a smart script that is
able to upgrade and adapt policies.
 
> 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.

If you mean setpriority() that can be implemented as a tiny setuid
program. Using systrace for privilege elavation is nothing else just
more complex. It's also possible to do this tranparently by replacing
the implementation of setpriority() at compile-time. systrace really
points out a flaw in this case. You shouldn't have to systrace for it,
instead the admin should be able to specify which user/group or
executable is allowed to use certain resources and to which extent.
That's more or less what POSIX capabilities is about and I believe
such a feature is in the making for NetBSD.

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

Let's consider MPlayer. It's very likely to be exploitable and people download
multimedia from all kinds of places. Of course, I've crippled it so that it
cannot use sockets except unix domain sockets which is required for X11. I
have a secondary policy that allows connecting to the internet but not reading
any files. Some people however might want to dump the video or audio to a file.
Of course, I don't let MPlayer write anywhere except to ~/.mplayer. Would you
allow this by default? If not, would you provide multiple policies? The
problem is that with the least common denominator you have to sacrifice so much
security that it becomes almost pointless.

People laugh about MP3-viruses and JPEG-viruses and stop abruptly as soon as
they get pwn3d by them - assuming they ever notice it.
 
> >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.

Templates require certainly less effort, maybe even little. It's just that
there's a similar danger as with firewalls and maybe even more.  Without
understanding how things work, you cannot configure neither a firewall nor
systrace properly. You might also consider yourself more safe than you actually
and become careless. Further, in both cases you'll likely break things. If you
have configured things yourself you will likely not blame anyone else for it
and be able to fix things yourself or at least know how to find help.

I hope you don't consider graphical tools to configure firewalls a good
counter example. Well, they might be sufficient for *very* basic stuff but
the very basic stuff is also easy with normal text-file configuration. I've
seen people blocking HTTPS without noticing it. So basically they exposed
them to much more security issues and of course they break procotols all
the time. Who reads firewall logs anyway?

Keep in mind that you can cause severe malfunction of applications by systrace
because you may easily expose them to failures which are almost or clearly
impossible otherwise. For example, you can make getuid() fail which can never
happen in real-life unless your CPU is in the process of melting. That's
why I believe more documentation and tutorials are much more useful than
pre-configured policies.

I'm not sure how many people actually use systrace because it has some
issues which I've never seen being discussed anywhere. For example, privilege
elevation might be nice but if everybody has to write his own wrappers to
do that, that's rather awkward. Also you can do plenty of things wrong even
in a simple wrapper, so at the very least, one would want to use well-written
stub.

Another thing is that you seemingly can't include rules from other files, I'm
not talking about inheriting rules. I don't want to manually allow read/write
and other basic syscalls which can't do harm for each and every policy. Do
people use a policy generator for this?

Last but not least, things are not completely determinate. Different usage,
different configuration of the program or the system are likely to cause some
syscall, some file to be used or not used. "systrace -A program" helps but
I almost always have to correct policies even after days because some things
happen only under certain circumstances.

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

Well, then try it for NetBSD only. I wouldn't really start such a project
before I have some test runs that show whether the necessary effort will
be manageable. Some OpenBSD guy has or had a similar project for systrace
templates but I can't find it momentarily.

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

You can simply install policies somewhere to /usr/pkg/ or not? I certainly
won't allow pkgsrc to write to /etc/systrace/.

-- 
Christian