[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Security patches

On Sun, 30 Nov 2003 15:32, Colin Walters <walters@verbum.org> wrote:
> However, this is not such a bad idea, if you don't try to be too formal
> about it.  If maintainers shipped English descriptions (say,
> README.Security) of what the security implications of their programs
> were, it could be very helpful for people writing security policies.
> These people would include the Debian maintainers of various security
> systems, as well as end-user system administrators.

Sounds reasonable.

> For example, the Apache maintainer might write (I'm making this up):
> README.Security:
> In its most basic configuration, this package runs as a daemon listening
> on port 80.  It does not require write access to any portion of the
> filesystem.  It has no sensitive files (such as cryptographic keys).

It also commonly needs to bind to port 443, if it does so then it needs to 
read SSL private key files somewhere under /etc.  In common configurations it 
needs to access ~/public_html or ~/www or ~/web for most users.  It commonly 
needs to create and access memory mapped files under /tmp.  It is reasonably 
common for it to run a SETUID root wrapper program named suexec or cgiwrap to 
run user CGI-BIN scripts under the correct UID.

In some configurations it may run as a web proxy, so it may need to connect to 
other local web servers.

Apache always needs to load shared objects from /usr/lib/apache/1.3 (or 
presumably /usr/lib/apache/2.0 for the new Apache).

This is just from memory, Apache configuration can be complex at the best of 

If we start asking dd's to write such plain-English policy statements for 
their packages we will probably soon discover that most of them don't know 
all the things that their package does.  When you write SE Linux policy for a 
daemon you often get surprised to discover that it does things you did not 
expect.  For example the way that cardmgr tries to create device nodes in 
several different directories, the way that lilo wants to create device nodes 
under /tmp, the way that sshd needs to run xauth for X forwarding, the way 
sendmail will bind to a high TCP port as part of it's startup process, the 
way that quotacheck needs to read every single file on the system, and lots 
more.  Some of these are things that seem obvious in retrospect (of course 
sshd needs to run xauth, the need for it is obvious but most people wouldn't 
think of it when describing sshd functionality).  Some of these are not 
obvious at all (quotacheck file reading and sendmail binding to a high port) 
and may even be considered bugs in the daemons.

http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Reply to: