On Wed, 15 Sep 2004 01:20, "Steve Coleman" <23e9t5t02(a)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