<snip> > We could add rules the same way firewalling rules are : in a boot script > using a userspace tool. > This mean that the policy is not there at boot time. It is not a problem > for those who use security policies as modules, but it is for those who > want to apply their security policy to boot scripts. > > An idea (utopia?) could be some persistent data mechanism in the kernel, > that could also be used for firewalling rules and other parameters > everywhere in the kernel. (I don't thought a lot about it... storing all > that in a file near the kernel image ? in the kernel image ? in a separate > dedicated partition ?) </snip> What about having the kernel store it somewhere (encrypted partition / fs ?) that is accesible via VFS (?) so that you cant read it past boot. the only way to write to this data area, is via a specific runlevel (i know adding a new run level) that is used only for editing security policies. when attempting to start in runlevel securityedit, must enter password (not root passwd!!!!), or key (PKI ?), enter a disk containing key (again PKI?) before access to that runlevel is allowed. for normal boot, kernel reads this data and stores it somewhere. once read, access (capability?) is then taken out of the kernel for that operation. i dont think that storing it in memory would be a security risk, as if userland / bad guy (tm) can read kernel memory, there is no security anyway. however, resources might be an issue (not sure??) -- The Celestial Wizard President - South East Brisbane Linux Users Group http://merlin.hatfields.com.au/seblug/ Red Hat Certified Engineer Master RedHat Linux Administrator Certification - Brainbench Master WindowsNT Administrator Certification - Brainbench I don't speak for Microsoft. So please don't speak for me. _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sun Apr 15 2001 - 22:00:03 PDT