SELinux policy and performance impacts

SELinux policy and performance impacts

[Matt Anderson]

I'm currently looking into the performance impact of SELinux.  Most of 
what I have seen so far involve testing the system's performance with 
file creation, open, and exec, but I was hoping to gather some more data 
before finalizing any conclusions.

I was wondering if anyone knows of any types of policy rules that when 
loaded into the kernel are particularly detrimental to system 
performance.  My understanding is that all policy rules are treated 
equally once they've been compiled to binary, but I wanted to ask here 
first in order to confirm that.

Thanks
-matt

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux policy and performance impacts

[James Morris]

On Thu, 7 Aug 2008, Matt Anderson wrote:

> I'm currently looking into the performance impact of SELinux.  Most of what I
> have seen so far involve testing the system's performance with file creation,
> open, and exec, but I was hoping to gather some more data before finalizing
> any conclusions.
> 
> I was wondering if anyone knows of any types of policy rules that when loaded
> into the kernel are particularly detrimental to system performance.  My
> understanding is that all policy rules are treated equally once they've been
> compiled to binary, but I wanted to ask here first in order to confirm that.

Yes, all access rules are applied in a standard form with decisions cached 
in the AVC.  There were some network permissions which had to do a full 
policydb lookup on each packet to determine the label to use, but these 
are also now cached (although will still incur some overhead).

Auditing will introduce overhead (not all accesses are audited).

Probably the best place to start to understand how this works is to look 
at avc_has_perm() in the kernel code, and also look at /selinux/avc .

I suspect the largest overhead will be in the hook logic for various
operations (e.g. look at the size of inode_doinit_with_dentry()) rather 
than the AVC lookup.


- James
-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux policy and performance impacts

[Paul Moore]

On Thursday 07 August 2008 8:03:02 pm James Morris wrote:
> On Thu, 7 Aug 2008, Matt Anderson wrote:
> > I'm currently looking into the performance impact of SELinux.  Most
> > of what I have seen so far involve testing the system's performance
> > with file creation, open, and exec, but I was hoping to gather some
> > more data before finalizing any conclusions.
> >
> > I was wondering if anyone knows of any types of policy rules that
> > when loaded into the kernel are particularly detrimental to system
> > performance.  My understanding is that all policy rules are treated
> > equally once they've been compiled to binary, but I wanted to ask
> > here first in order to confirm that.
>
> Yes, all access rules are applied in a standard form with decisions
> cached in the AVC.  There were some network permissions which had to
> do a full policydb lookup on each packet to determine the label to
> use, but these are also now cached (although will still incur some
> overhead).

As an FYI, you'll want 2.6.26 to get the all of the cached network 
permissions; 2.6.25 added interface and node caches, 2.6.26 added port 
caches.  If you are looking at network performance as part of this you 
will want to make sure compat_net is disabled, i.e. use Secmark.  

Ideally you would also enable the new network_peer_controls policy 
capability but I don't think we have that enabled by default just yet, 
needs more testing I believe.

-- 
paul moore
linux @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux policy and performance impacts

[Joshua Brindle]

James Morris wrote:
> On Thu, 7 Aug 2008, Matt Anderson wrote:
> 
>> I'm currently looking into the performance impact of SELinux.  Most of what I
>> have seen so far involve testing the system's performance with file creation,
>> open, and exec, but I was hoping to gather some more data before finalizing
>> any conclusions.
>>
>> I was wondering if anyone knows of any types of policy rules that when loaded
>> into the kernel are particularly detrimental to system performance.  My
>> understanding is that all policy rules are treated equally once they've been
>> compiled to binary, but I wanted to ask here first in order to confirm that.
> 
> Yes, all access rules are applied in a standard form with decisions cached 
> in the AVC.  There were some network permissions which had to do a full 
> policydb lookup on each packet to determine the label to use, but these 
> are also now cached (although will still incur some overhead).
> 

When the SS originally makes the decision (before its been cached) there is additional overhead on rules and types using attributes. Because of the avtab compression from version 20 the source and target types will be looked up in a reverse mapping to attribute, then each attribute will be looked up in the avtab to get the net access vector. More attributes (within reason) means less memory usage and more lookup overhead. For tests that repeat the same kinds of accesses over and over this overhead should be reduced to nothing by the AVC, however.

> Auditing will introduce overhead (not all accesses are audited).
> 
> Probably the best place to start to understand how this works is to look 
> at avc_has_perm() in the kernel code, and also look at /selinux/avc .
> 
> I suspect the largest overhead will be in the hook logic for various
> operations (e.g. look at the size of inode_doinit_with_dentry()) rather 
> than the AVC lookup.
> 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux policy and performance impacts

[Stephen Smalley]

On Thu, 2008-08-07 at 19:13 -0400, Matt Anderson wrote:
> I'm currently looking into the performance impact of SELinux.  Most of 
> what I have seen so far involve testing the system's performance with 
> file creation, open, and exec, but I was hoping to gather some more data 
> before finalizing any conclusions.
> 
> I was wondering if anyone knows of any types of policy rules that when 
> loaded into the kernel are particularly detrimental to system 
> performance.  My understanding is that all policy rules are treated 
> equally once they've been compiled to binary, but I wanted to ask here 
> first in order to confirm that.

In addition to other points raised in this thread, note that using
larger inodes (as done by default in F9) should yield a significant
improvement in file benchmarks by keeping the SELinux security context
inline within the inodes rather than in separate data blocks.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.