Securing more than files with ACL
Groups
The ACL module can be used to secure more than just files.
Defaults too secure. GROUP option. :DEFAULT: Add READ to 'Everyone'. Remove root.
Limitations of ACL
While the ACL module can provide additional flexibility, and the ability to implement a finer grained security policy than can be achieved with the standard Linux filesystem controls, it is limited by its dependence on traditional users and groups.
To illustrate this limitation lets use an example. Imagine that you wanted to secure daemon processes started by root with different security policies depending on the type of process. The syslog process should be able to read from /proc/kmsg and write to any log files which are being kept. The cron process, on the other hand, needs to be able to read user configured crontab files and send emails containing the output of jobs.
Using ACL alone there are only two alternatives, neither of which are particularly appealing.
- Assign all the permissions required by all daemon processes to the root account.
- Make every process run as a different, non-root user.
The first solution is clearly unacceptable as we would be hardly any better off than with just the standard Linux filesystem permissions. Processes would still be able to trample all over each other, read and possibly modify files they have no need to be able to access, etc.
The second solution has more promise, it would allow us to isolate processes from each other and the rest of the system. It does, however, require that every process we intend to run be capable of being started and run under a non-root account or be capable of switching to a non-root user on its own.
The above reasons are just some of the problems which the Role Compatibility model was created to solve. In the next few chapters we shall explore the RC model and see how it can be used to implement a security policy.
