2000 UK Linux Developers' Conference
Linux for the Enterprise
7 - 9 July 2000, Hammersmith (West London)
What is a Security Policy and why should you care?
A security policy defines the allowed methods of access by processes (as initiators or subjects) to various objects in the system. Objects include other processes, pipes, files, IPC objects and possibly others.
In order to know if something is broken, one needs to know what the intent of the kernel is in controlling or regulating access. Security policy focuses on what is allowed to unprivileged users. It also defines ways in which security policy may be suspended through use of privilege. An example of this is root accessing a user file. Root may have the privilege to override Discretionary Access Controls that would normally prohibit others from accessing the file.
Access to different objects is based on the object's type. Some objects are read-only constants (such as the cpu type). Other objects may be read-only and only modified by use of privilege (such as the System Clock). The permissions used to control access to an ext2 file system are going to be different than those regulating access to an msdos file system.
The security policy has been derived primarily from the only documentation available: the source. The source is a moving target and this document attempts to reflect the latest kernel that is stable or about to be stable.
The final document will need to evolve as Linux security evolves in order to remain useful. However, hopefully it will be a reference to base implementation on and to verify code against (i.e., does doing X break policy; if so, how and why and change the policy). I am also personally challenged with the task of how to make mundane Linux Security Policy sexy enough to get people involved and interested.
Linda works in the Trust Technology group at Silicon Graphics. She has been with SGI since 1995, and has previously worked at Intel, Sun, and several start-ups. She has an engineering degree in Computer Science from the University of Illinois. In previous positions, she has worked in compilers, run-system design, networking, test control and automation, and application portability.
|S P O N S O R S|
For more information please contact UKUUG.
Problems? e-mail webmaster
© Copyright 2000 UKUUG Ltd