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