by James Morris

[permalink] [raw]

Subject: Re: The price of SELinux (CPU)

On Tue, 4 Oct 2005, John Richard Moser wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've heard that SELinux has produced benchmarks such as 7% increased CPU
> load.

The overall performance hit across several micro and macro benchmarks,
when last measured last year sometime, was around 7%, depending on
workload and what you were testing. It's a very rough figure and any
serious benchmarking needs to be done for the intended workload.

The AVC is now linearly scalable (measured up to 32 processors) thanks to
RCU and work by NEC.

> Is this true and current? Is it dependent on policy? What is
> the policy lookup complexity ( O(1), O(n), O(nlogn)...)? Are there
> other places where a bottleneck may exist aside from gruffing with the
> policy? Isn't the policy actually in xattrs so it's O(1)? Where else
> would an overhead that big come from aside from a lookup in a table?

The overhead is generally independent of policy size, as policy is cached
in the AVC and most workloads use a trivial number of policy rules in a
steady state (often less than 20).

So, generally, you'll only have a very small number of AVC entries active,
although you could have some longish hash chains if policy has not been
reloaded since boot.

Look in /selinux/avc for stats.

Googling for "selinux performance" will guide you to:
http://www.livejournal.com/users/james_morris/2153.html

- James
--
James Morris
<[email protected]>

2005-10-04 15:39:29

On Tue, 04 Oct 2005 14:29:05 EDT, John Richard Moser said:

> 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. . . .

Virus writers are users too, you know. :)

And the other users are users as well - what if the other user's "idiotic
action" is to nuke your 500Mbyte archive of alt.binaries.pictures.llama.sex
that's taking up the disk space that is keeping him from running the payroll
software? In your world, rather than him being able to fix the problem, he has
to go find a sysadmin with the root password to fix it, causing delays and
being less friendly....

You seem to be intentionally trying to miss the basic point, which is that
any additional security ends up trading off against other things.

Non-execute stack is a Good Thing security-wise - but it breaks some code,
forcing upgrades and/or having to track down binaries and flag them as
"don't enforce NX stack". And then those binaries are still vulnerable....

SELinux is, in general, also a Good Thing. However, the fact that the policy
restricts what stuff can happen in the security context associated with
mail delivery (after all, you *don't* want arbitrary binaries running then, right?)
did some serious damage to the way I use procmail, which in some cases ended
up running other binaries. OK, so my .procmailrc *is* a 600-line monster that
does a lot of odd stuff - the point was that I had to add even *more* contortions
to the way it works, which is even less user-friendly....

Attachments:

(No filename) (226.00 B)

2005-10-04 20:11:57

by John Richard Moser

[permalink] [raw]

Subject: Re: The price of SELinux (CPU)

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

[email protected] wrote:
> On Tue, 04 Oct 2005 14:29:05 EDT, John Richard Moser said:
>
>
>>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. . . .
>
>
> Virus writers are users too, you know. :)
>
> And the other users are users as well - what if the other user's "idiotic
> action" is to nuke your 500Mbyte archive of alt.binaries.pictures.llama.sex
> that's taking up the disk space that is keeping him from running the payroll
> software? In your world, rather than him being able to fix the problem, he has
> to go find a sysadmin with the root password to fix it, causing delays and
> being less friendly....
>

Oh sure, except that. . .

1) You shouldn't be screwing with the payroll system
2) You're quota'd on any good setup
3) You're fired

> You seem to be intentionally trying to miss the basic point, which is that
> any additional security ends up trading off against other things.
>

It does, but put the degree to which it trades off in perspective.

Utilizing ProPolice, functions which contain a local character pointer
(char[]) are guarded. These functions experience a minimal performance
hit; practically it can top-out at around 8% theoretical, although from
my perspective you could produce an empty function where the guard code
is 100% of its body. The 8% theoretical is along the lines of:

void foo() {
char a[6];
strcpy(a, "hello");
}

Obviously strcpy()'s complexity decreases the overhead; this is some
strange hybrid of "theoretical maximum" with "practical maximum," which
comes out to be "theoretical practical maximum" which is nonsense, but
we'll just for the sake of discussion let that slide.

Anyway, a finite number of functions have such guard code; and the
overhead can be shown as a function y=1/x, where y is the overhead and x
is the number of units of code run between entering and exiting the
function, assuming the code added by propolice is 1 unit. In the end,
the overhead is pretty much nil for practical applications.

For your trade-off of some practical 0.1% increase in CPU load, your
applications do two things when a stack buffer is overflowed. First,
they tell you what function produced the buffer that was overflowed, in
what source file; second, they immediately terminate (complain loudly).

This means that things that are fuzz may crash the program; but so will
attacks. It also means that these crashes are easy to report in
valuable detail, and thus the bugs are fixed rather quickly. In the
end, this produces cleaner, more stable code due to attention being
brought to bugs more directly. Additionally, such bugs would cause
intermittent odd behavior ranging from things not working to program
freezes to data corruption; a sudden crash in place of these things is
hardly much of a trade-off. Finally, deploying such a protection
doesn't suddenly unearth massive amounts of buggy code, because if there
were such bugs in force then there'd be massive amounts of odd behavior
already.

So you've traded nearly nothing in the practical sense for a great
enhancement in security in this example. In some special applications,
a program with its own bug will trigger this, which may be a more major
trade-off; but you need access to the source code to add this protection
to anything anyway, so in this case it's just going to tell you how to
fix the bug anyway.

> Non-execute stack is a Good Thing security-wise - but it breaks some code,
> forcing upgrades and/or having to track down binaries and flag them as
> "don't enforce NX stack". And then those binaries are still vulnerable....
>

Right. It breaks some (very little, typically) code. Perspective please.

> SELinux is, in general, also a Good Thing. However, the fact that the policy
> restricts what stuff can happen in the security context associated with
> mail delivery (after all, you *don't* want arbitrary binaries running then, right?)
> did some serious damage to the way I use procmail, which in some cases ended
> up running other binaries. OK, so my .procmailrc *is* a 600-line monster that
> does a lot of odd stuff - the point was that I had to add even *more* contortions
> to the way it works, which is even less user-friendly....
>

Special case that would have likely never arisen if you had such
restrictions when you started; or in the very least would have been
solved more elegantly.

>

In the end, massive, intrusive security is not exactly the best thing
for security's sake; but anything you can get away with significantly
cleanly (i.e. you don't break 99% of the applications on 99% of home
users' desktops) is worth immediate focus for those who are so inclined.

- --
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

iD8DBQFDQuGhhDd4aOud5P8RAtbhAJ9p22xB3KhPQ9iywk7ug6VbAgKFlQCeN9Yp
si7fx6ngk4UU/H8KTNgeR0U=
=soXe
-----END PGP SIGNATURE-----

2005-10-04 20:35:44

by Bill Davidsen

[permalink] [raw]

Subject: Re: The price of SELinux (CPU)

Dan C Marinescu wrote:
> the benchmark "results" _look_ like being authored by
> some qa engineers... or sysadmins or something...
>
> *** only a deep/intimate knowledge of kernel and fs
> and acl implementation details and many other areas
> could suggest a credible conclusion (most likely
> without even needing any "profiling" at all... on pure
> theoretical basis, mostly because you would know what
> goes where and when and how and why and how much it
> adds here and there, etc, etc, etc)

Any results not based on actual measurement are called "guesses" rather
than "data." Such deep knowlege is useful to determine what to measure,
not what you would measure if you thought it were necessary.

The measurements are very useful, in that they show the magnitude of the
performance impact using a benchmark which was constructed to emulate
certain real world loads. Since no one number or even series of numbers
can fully describe what *will* happen, but these numbers show what
*could* happen.
>
> and i personally have a strong doubt that if the cpu
> activity was statistically increased with 7% for the
> very same elementary I/O, linus would have accepted
> this degradation... my $0.02... :-)

For some applications the issue isn't how fast the O/S runs, but if it
is secure enough to be run at all. Given the speed of even commodity
computers, it's probable that even a 2:1 slowdown would still result in
useful operation, compared to doing the work without a computer.

I can't speak for Linus' thinking of course, but I have worked in secure
environments before, both DOD and DOE, and information control is vital.

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2005-10-04 22:24:46

by Dan C Marinescu

[permalink] [raw]

Subject: Re: The price of SELinux (CPU)

> Any results not based on actual measurement are
> called "guesses" rather
> than "data." Such deep knowlege is useful to
> determine what to measure,
> not what you would measure if you thought it were
> necessary.

in my world, we design stuff, calculate bigO, then
implement and finally measure. we don't write code at
inspiration and then measure and if kinda s*x we apply
patches then measure again, etc etc etc, that's _all_
i meant... (keep measuring something not really
designed for this O or that O may be a huge waste of
time). even in qa, the best engineers find
short-cuts... even in black box testing, but then you
get gray box, and white box testing and finally us
(r&d).

> The measurements are very useful, in that they show
> the magnitude of the
> performance impact using a benchmark which was
> constructed to emulate
> certain real world loads. Since no one number or
> even series of numbers
> can fully describe what *will* happen, but these
> numbers show what
> *could* happen.

correct, but you should measure something which you
first designed then implemented... not the other way
around...

> > very same elementary I/O, linus would have
> accepted
> > this degradation... my $0.02... :-)
>
> For some applications the issue isn't how fast the
> O/S runs, but if it
> is secure enough to be run at all. Given the speed

hey, absolutely... i was about to add that too (last
night) but it was kinda late... but how would you
define "secure"... it's kinda like huge, eh? in my
$0.02, secure means secure enough for the purpose
(whatever that may be...) and it's way over the scope
of this email... when this is equivalated with "oh,
it's kinda slow, but it's worth cause it's safer"...
well, i kinda have doubts on that... (check for a
second oppinion in your sec strategy, etc...)

> of even commodity
> computers, it's probable that even a 2:1 slowdown
> would still result in
> useful operation, compared to doing the work without
> a computer.

well, yes and now... it's a long story...

> I can't speak for Linus' thinking of course, but I
> have worked in secure
> environments before, both DOD and DOE, and
> information control is vital.

yeah... remember the old days (running around with
floppies because networking was "unsafe" blah blah
blah...)

nice talking 2u bill,
d

>
> --
> -bill davidsen ([email protected])
> "The secret to procrastination is to put things off
> until the
> last possible moment - but no longer" -me
>

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

2005-10-04 22:32:33

[email protected] wrote:
> On Tue, 04 Oct 2005 16:10:10 EDT, John Richard Moser said:

>>Oh sure, except that. . .
>>
>>1) You shouldn't be screwing with the payroll system
>>2) You're quota'd on any good setup
>
>
> Ahem. You're adding in more "user unfriendly" constraints again. :)

I don't think promising a user that s/he can have N MB of disk is
unfriendly at all.

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me