The standard Unix security model is showing it's age --- it is no longer adequate for 24/7-networked machines. In this section we consider the ultimate security add-ons to Linux: kernel-patches which extend this standard model. In particular, we introduce Medusa DS9 which extends the Unix security architecture for Linux by offering fine-grained file protection, virtual spaces in which services/daemons (for example) can operate and system call monitoring. We also mention other, similar, software.
From the Medusa web site: Medusa is a package that improves the overall security of the Linux OS by extending the standard Linux (Unix) security architecture while preserving backward compatibility. Briefly, it supports, at the kernel level, a user-space authorization server (and is thus fully transparent to any user space applications). Before the execution of certain operations, the kernel asks the authorization server for confirmation. The authorization server then permits or forbids the operation. The authorization server can also affect the way an operation is executed in some cases, which are described later. This method allows the use of almost any security architecture. When the authorization server is properly configured, it can determine access rights within the system to a very fine level and do very good auditing.
Medusa consists of two parts: some kernel patches and a user-space daemon (authorisation server) called Constable. Constable is controlled by its configuration file, usually /usr/local/etc/constable.conf.
Currently only Linux/Intel is supported but Medusa is being ported to *BSD and Solaris.
This fragment from constable.conf prevents deletion of a given file, even by root (even with writable file-attributes set):
for unlink "/tmp/my_file" {
log "User " uid " tried to delete file " data;
log "Process information:";
log_proc;
answer = SKIP;
}
|
for exec "/sbin/ifconfig" {
if (euid != 0) {
redirect "/bin/date";
}
}
|
Medusa's virtual spaces can be thought of as generalised chrooting (without the hassle): any process or file can be assigned to a virtual space; processes in one virtual space cannot see or change processes or files in another virtual space. The following comment from (the top of) one of the supplied sample configuration files describes the obvious application of virtual spaces:
// Sample configuration file.
// (C) 1999 Marek Zelem
// (C) 1999,2000 Milan Pikula
// This comes as a part of the Medusa DS9 package.
//
/*
* This will divide the system into `local' and `network' parts. If
* a process is local, it can do almost anything. If it's `network', it
* can see only selected files and perform only a few actions. You don't
* need to specify which process will be `local' or `network' - a process
* becomes `network' when it creates an inet socket (that means that
* it will affect both incoming and outgoing connections, both TCP
* and UDP (well, raw too..).
*/
suid programmes create well-known security headaches. One can use Medusa to control access to such programmes. In this example we prevent remote users (who have connected via the telnet daemon) from executing suid programmes.
for exec "/usr/sbin/in.telnetd" {
flags = 1; // flag this process
proact = P_SEXEC; // monitor when this process tries to run suid prog
}
on sexec {
if (flags == 1) {
answer = NO; // don't let'em run it
}
}
|
The really paranoid will note that if a second telnet daemon is installed (and not listed in the above configuration) it will be able to execute suid programmes. Such programmes can be found by monitoring system calls.
There are several other pieces of software which upgrade the standard Unix security model, including:
| ...previous | up (conts) | next... |