2 General overview

The standard Linux Kernel meets Division C, Class 2 "partially'' in Audit context, since there is no system routine which records events of object introduction or deletion.

Once this problem was solved, to reach Division B, Class 1:

(a)

the audit record will have to include, for each event that either introduces an object into a user's address space ot it deletes an object, the name of the object and the object's security level.

(b)

Moreover, the system manager would have to be able to selectively audit the actions of any one or more users based on individual identity and/or object security level.

(c)

Finally, it must be possible to audit any override of human-readable output markings.

To reach Class 3,

(d)

one of the required features is the presence of a mechanism that is able to monitor the occurrence or accumulation of security auditable events that may indicate an imminent violation of security policy. This mechanism will have to be able to immediately notify the security administrator when thresholds are exceeded, and, if the occurrence or accumulation of these security relevant events continues, the system will have to take the least disruptive action to terminate the event.

(e)

Moreover, we would need some mechanisms for the identification of events that may be used in the exploitation of the usage of covert storage channels.

In this paper, we will describe an extension of the standard Linux Kernel to reach Division C, Class 2 and that solves problems (a)-(d) as well. Problem (e) currently is solved for a particular case: File Flag Communication. With this term we intend a illegal communication from root to user processes based on file presence that indicates, for example, a bit information, but this needs more work.

Now we will describe a list of typical attacks [2].

• A system cracker telnets to the next site on his hit list. "guest - guest", "root - root", and "system - manager" all fail. It does not matter. A lot of sites have easy passwords to crack, based on user name, birth date and so on.
• NFS-Attacks. For instance, running showmount on a target reveals that /export/foo is exported to the world. In this case you can put an .rhosts entry in the remote guest home directory, which will allow you to login to the target machine without having to supply a password!
• Anonymous ftp attacks. Vulnerabilities in ftp are often a matter of incorrect ownership or permissions of key files or directory.
• X windows attacks. If not protected properly (i. e. via xhost or magic cookie mechanisms) window displays can be captured or watched.
• Denial of Service attacks. These type of attacks do not involve a penetration in a system. They slow or block a net service or the entire system.
• Sendmail attacks. Sendmail is a very complex program that has a long history of security problems, i. e. running the ``decode'' alias is a security risk: it allows potential attackers to overwrite any file that is writable by the owner of that alias, often daemon, but potentially any user.
• ``hosts.equiv'' attacks. The hosts recorded in this file are trusted: for example if a login request come from a site recorded in hosts.equiv file, there is no need to supply a password. Any form of trust can be spoofed.
• Buffer exploit attacks. If a malicious user finds a buffer overflow in a suid utility, he can gain root privilege.
• Password sniffing. The telnet sessions do not use any form of encryption; so an attacker can sniff the password during a telnet session.

New forms of attacks appear every day. This list can only be a short example.