Security criteria

Robert Connolly cendres at
Mon Jan 5 10:15:44 PST 2004

This is mainly pulled from department of defense orange book standards. Keep 
in mind these standards are 20 years old. It would be nice to expand on this 
in our own modern words. Standards like this should get positive interest 
from commercial users; to be able to insure a system.

Minimum requirements, even for a D class rating, involves mandatory access 
control of all classified data. This would include /etc/shadow, home 
directories, temp files. I think this would be better if all objects are 
default deny, so a normal user can't access /bin/bash without explicit 
permission. I think filesystem access controls, and grsec can do something to 
help this. This would definitely affect /proc too. So if a process escapes a 
jail it wouldn't have read or execute permission on anything, and if it tried 
accounting would catch it. Nor should these proccesses be able to write to 
temp directories. More group permissions, less other permissions.

Accounting for security related events, logins (failed or otherwise), suid 
useage, shadow file access, new files. Logs need to be tamper proof, either 
by remote logging, or printing on paper.

Logins obviously need to be secure. Password authentication seems to be the 
standard, but not as good as dna and/or retinal scans. This would mean 
running cracklib or some other password checker on new passwords, and 
rejecting short or easy ones. Word lists should be in more languages than 
english, what are the second and third most common languages?; chinese and 
french I think. I theorize a dynamicly linked suid passwd program could 
accept malicious code to bypass cracklib, so password checking should also be 
done at login. To keep this extra login checking from becoming a denial of 
service, logins are default deny by the daemon, and anything else upstream, 
before a password is evalutated.

Periodic system integrity checking to validate objects on the system. I think 
this would need a cron daemon unless there's another way (make syslog do it). 
Have an fsck after a set amount of mounts. sha1sum the read only parts of the 
system weekly and report the results. Exported logs also need integrity and 
authenticity checks.

Software needs to be tested to make sure it does what it says in the 
documentation, and offers no obvious ways for a malicious process to defeat 
another security mechanism. Imported data has to be given a security 
evaluation and given need-to-know permissions. Adjustments to file system 
permission should be done manualy (I know of some package systems that tamper 
with the filesystem to satisfy a configure script). I suggest /etc should be 
the only configure file directory. All files in /etc should be owned by root 
and not writeable by anyone else; except for chroot daemon files, which fit 
in /var/chroot, and also owned by root, with group write where its needed.

I also think rbash, or equvilent, should be used for all scripts run as root 
(boot, etc). This would mean hardcoding enviroment vars and maybe some script 
rewritting to match.


More information about the hlfs-dev mailing list