On Wed, 15 Sep 2004 01:20, "Steve Coleman" <23e9t5t02@xxxxxxxxxxxxxx> wrote: > I think that the CODA project would be an excellent match for your > stateless linux concept. It combines the sort of stateless distributed > > http://www.coda.cs.cmu.edu/ CODA has some nice features, but for some reason it doesn't seem to get used. I would like to see some reviews from sites that use it before considering using it. Also we need SE Linux support for any file system we use. Does CODA support XATTRs? If not it'll be a real PITA to get support implemented. > What ever you come up with, in my opinion, MUST support SELinux but not I agree. > needed. Adding SE to the initial boot cycle you would ensure better > control over the network bootstrap process so that it will be harder to > hack into, as network loading of images is inherently vulnerable since > the logic needed for proper validation of the image must have been GPG signing of boot files or another similar method of avoiding a MITM attack over the net is more important than SE Linux. Even easy things like running rsync over ssh achieves this goal. > cached already or the security contexts transferred first. Changing the > boot up sequence necessitates getting some SE gurus in on your design When there is something to test I'll test it and provide feedback on what needs to be done for SE Linux. > early because the permissions must be labeled in the file system and > permissions granted in the right sequences, otherwise the SE system > will have major problems booting up. I think you need a form of > distributed SE profiles which are used to bootstrap the network loading > of the OS and relabeling of the root filesystem and runtime cache > images. I'm no guru on SE but I know its not going to be trivial. That part shouldn't be difficult. Currently most SE Linux users are expected to use binary policies, so we are planning to have minimal divergence of policy for most users. So having one policy binary for all should do. Policy modules will make this even easier. > Another suggestion I have is to have a long term objective of > incorporating OpenMosix like capabilities in order to add application OpenMosix isn't in kernel.org and we won't support any kernel features that aren't in kernel.org. Also OpenMosix does not support SE Linux (shouldn't be difficult to make it work as long as all machines have the same policy, but it's something that has to be done). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
