On 8/29/06, Andrew Reilly <andrew-netbsd@areilly.bpc-users.org> wrote:
> How can someone else write my security policy for me?

Well, I think "security policy" is an overloaded term, so let's talk about
"SELinux policy".

For example, we know in advance that sendmail will write to mail spool files
in /var/spool/mail.  And that it binds to TCP port 25.  And to fork off certain
programs.  And so on.  So we give sendmail permission to just do those
things, and nothing else.  Sendmail does not usually need to spawn xterm.

Now, you may run sendmail on port 8025, in which case you might have to
modify the policy.  I found that it was necessary to load a new policy module
to enable procmail and some utilities that it spawns.  But so far
that's all I've
had to do.

For the most part, the code defines the allowable actions, and one can do a
static analysis, or run it in permissive mode for a while to document the
system calls it uses at run-time.  What it doesn't need to do is the
things typical
of intrusions.

You can think of this as being similar to the distro defining the
permissions and
owners of file system directories and files, like they do in /etc/mtree.

> What sort of applications are we talking about?

Mostly exposed network daemons, like httpd, sendmail, and perhaps
bind.  Since these are usually provided as services for remote systems,
they are a common intrusion vector.  Other daemons like nfsd are
not typically made available through the firewall, so do not require as much
attention.
-- 
"If you're not part of the solution, you're part of the precipitate."
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484