On Aug 21, 2007, at 11:50:48, Casey Schaufler wrote:
--- Kyle Moffett <[email protected]> wrote:
Well, in this case the "box" I want to secure will eventually be
running multi-user X on a multi-level-with-IPsec network. For
that kind of protection profile, there is presently no substitute
for SELinux with some X11 patches. AppArmor certainly doesn't
meet the confidentiality requirements (no data labelling), and
SMACK has no way of doing the very tight per-syscall security
requirements we have to meet.
And what requirements would those be? Seriously, I've done Common
Criteria and TCSEC evaluations on systems with less flexibility and
granularity than Smack that included X, NFSv3, NIS, clusters, and
all sorts of spiffy stuff.
These are requirements more of the "give the client warm fuzzies".
On the other hand, when designing a box that could theoretically be
run on a semi-public unclassified network and yet still be safe
enough to run classified data over IPsec links, you want to give the
client all the warm fuzzies they ask for and more.
I mean, if the requirement is anything short of "runs SELinux" I
have good reason to believe that a Smack based system is up to it.
"up to it", yes, but I think you'll find that beyond the simplest
policies, an SELinux policy that properly uses the SELinux
infrastructure will be much shorter than the equivalent SMACK policy,
not even including all the things that SELinux does and SMACK doesn't.
I didn't make this clear initially but that is the kind of system
I'm talking about wanting to secure some 50 million lines of code on.
Cool. SELinux provides one approach to dealing with that, and the
huge multiuser general purpose machine chuck full of legacy
software hits the SELinux sweet spot.
Well, given that 99.9% of the systems people are really concerned
about security on are multi-user general-purpose machines chuck full
of legacy software, that seems to work just fine. If it's a single-
user box then you don't even need MAC, just a firewall, a good locked
rack/case/keyboard/etc, and decent physical security. If it's
entirely custom-controlled software then you can just implement the
"MAC" entirely in your own software. "General-purpose" vs "special-
purpose" is debatable, so I'll just leave that one lie.
Replying to another email:
but you written it in wrong language. You written it in C, while
you should have written it in SELinux policy language (and your
favourite scripting language as frontend).
I have often marvelled at the notion of a simplification layer. I
believe that you build complex things on top of simple things, not
the other way around.
There is no "one answer" to this question in software development.
Generally you prioritize things based on maximizing maintainability
and speed and minimizing code, bugs, and complexity. Those are often
both conflicting and in agreement. Here are a few common examples of
simple-thing-on-complex-thing:
* pthreads on top of clone()
* open(some_string) on top of all the complex VFS machinery
* "netcat" on top of the vast Linux network stack including
support for arbitrary packet filtering and transformation.
In addition, "simple" is undesirable if it makes the implementation
less generic for no good reason. Would you want to use the "simple"
MS Windows disk-drive model under Linux? Every disk is its own
letter and has its files under it. Oh, you wanted to mount a
filesystem over C:\tmp? Sorry, we don't support that, too bad.
Under Linux we have a very flexible and powerful VFS which lets you
do very crazy things, and then for the user's convenience we have
various "simple" interfaces (like Gnome/KDE/XFCE).
Software development is very much about finding the Right Model(TM)
to underlie the system, and then building any simplifications-to-the-
user on top of the very simple model.
Look at the SELinux model again; it has the following things:
(A) Labels on almost-all user-visible kernel objects
(B) Individual access rules for almost every operation on those
objects
(C) "Transition" rules to set the label on newly created objects.
(D) Fundamental "constraints" which enforce hard limits on what
may be permitted with "allow" rules
From a fundamental standpoint it's harder to get much simpler than
that. On top of that model, we also have a bit of additional
*flexibility* for MLS/RBAC, although that flexibility may be ignored
completely.
(1) You can define "users" which may only assume some "roles"
(2) You can define "roles" may only run in some "types"
(3) There's a simple way of declaring multiple "levels" and
"dominance".
So you see, SELinux is a pretty fundamental description of the
degrees of flexibility needed to secure everything. That kind of
FUNDAMENTAL description is what belongs in the kernel. Anything else
can and should be built on top with better libraries and/or user
interfaces.
As for the script, I'm partway through debugging it but my time is
all chewed up with other stuff now, so it may take me an extra couple
days.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
