Re: The price of SELinux (CPU)

[John Richard Moser <nigelenki@comcast.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Valdis.Kletnieks@vt.edu wrote:
> On Tue, 04 Oct 2005 00:28:40 EDT, John Richard Moser said:
> 
> 
>>At any rate, my personal end goal is a secure high-performance operating
>>system, as user friendly as 
> 
> 
> Step 0: Sooner or later, "secure" and "user friendly" *will* come into conflict.

It's a lot later than you think.  A home desktop OS isn't a server OS;
and a server OS isn't a home desktop OS.  That being said, something
doesn't have to be as wide-open as the goatse guy's ass to be suitable
for every tom dick and moron.

> At that point, you have to make a choice. Note that in many cases, we *made* the
> choice years or even decades ago, and we've gotten used to the choices made.
> For instance, you'd certainly get better performance and user friendliness if
> you just stubbed out permission() in fs/namei.c and capable(), and just had them
> return "let the guy do it".  But somehow, I don't think anybody would find that
> very palatable.
> 

Would you now?  The performance gain would be negligible, even if it
were there; the user friendly factor would be pretty nil.  I mean the
user now can administrate his system without entering a password before
hitting the configuration center -- which he does every several weeks if
that.

Aside from this, viruses and spyware and worms can now run rampant and
do what they want to his system, and other users' idiotic actions on a
multi-user system affect him.  This is more user friendly?  No, I think
it's going in the opposite direction. . . .

The choice was made at Windows with "Let the desktop user run as
administrator;" in Linux it's typically made at "We've designed an OS
that runs very, very well with your account limited."  They're both
roughly equivalent in terms of user friendly (I think linux with Gnome
or KDE is actually easier, so does my mom).

> Similarly, the stuff that comes out of Redmond, in general, has security issues
> precisely because they chose "user friendly" when they got to Step 0.  Being
> able to put Javascript and/or executable binaries in e-mail for automatic
> execution is certainly user-friendly - but it's not secure.
> 

There's "user friendly," and then there's just ass.  Switzerland gives
each and every child a rifle and trains them to use it at age 12 IIRC;
this would be "user friendly."  Now, if you want to be just ass, hand
every 4 year old a gun with live ammunition and wait for them to put a
bullet in someone's brain and learn on their own that you shouldn't
shoot people unless you really mean it.

Open source programs achieve "user friendly" in a responsible manner.
Firefox doesn't have a local machine zone with javascript able to write
to files directly; thunderbird doesn't auto-run certain scripts; the
file browser isn't integrated into the web browser in anything but KDE
(which I personally dislike for other reasons).

> In any case, the overhead isn't 7%.  If anything, it's probably closer to 0.7%,
> and dropping with each kernel release as the code gets tuned and optimized even
> more.  And beware the impact of micro-optimizations and macro-performance - there
> was recently a code change to reduce the number and size of avtab entries.  That
> slowed down the actual code path slightly, but overall was actually a performance
> win, especially on smaller memory-constrained machines, due to the drastic drop
> in overall slab consumption.

Nice.  Some IBM guys said they're gonna rebench soon so I'm looking
forward to that, but this is reassuring.

> 
> And remember - the first time that a security system prevents (for example) an
> exploit against an Apache bug from being used to take over a system, it's paid
> for itself.  When the FBI faxes you that "Hold Evidence" order, it means you may
> not be seeing that server again for weeks, if ever.....

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDQsnwhDd4aOud5P8RAmmWAJ9JJquzIPzjVlm5w0OxrBAwOJP6gwCeOHYv
sVpFxYCDZvKbhUOq86dqog4=
=i9Fd
-----END PGP SIGNATURE-----