Excellent answer... its been too long since I've played with selinux.
I'll try again.
> I once thought about re-implementing LoMAC as a ruleset atop of
> I'm pretty sure that this is possible, but I started thinking that the
> complexity of the ruleset may introduce holes that voids the effort.
> And that thought disturbed me.
It isn't actually possible to implement LOMAC via SELinux, but that's
Hmm, why not?
> Along with Lomac's 'bluntness' comes 'zero
> something that could be installed on the proverbial 'Grandma's Linux
> desktop', and provide additional security without causing pain.
Until Grandma wants to do useful work. Simple security models are nice
to look at, but they don't capture the behavior of real systems, and it
doesn't matter that the model is "secure"; you just break one of the
trusted subjects authorized to override the security model in order to
get the real work done. SELinux policy may look weaker to you, but it
actually represents what is being allowed in the system; no exceptions.
I don't quite understand this. I'm currently running Lomac on one of
my servers, and I can get work done. It seems to be usable, even if
it makes some operations, like software install, harder.
I'm not sure what you mean by 'break a trusted subject'. If you mean
'ssh is trusted, so if ssh is broken, all hope is lost', then yes.
But surely selinux has trusted subjects that may not be trustworthy?
If you mean 'lomac provides explicit tools that allow a sysadmin
to manually move a file from lower to higher trust domains', then,
well, I'm also confused. Surely selinux also has a way to start
with something untrusted, and then raise its level ... e.g. to
install software downloaded from the net.
Is the 'broken-ness' the fact that grandma failed to run an anti-virus
scanner and verify checksums, yada yada, before elevating the
priveldge on the downloaded software?