"Stateless Linux" project

[Russell Coker]

On Wed, 15 Sep 2004 01:20, "Steve Coleman" <23e9t5t02 at sneakemail.com> 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