All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: Michal Marciniszyn <michal.marciniszyn@gooddata.com>,
	selinux@tycho.nsa.gov
Subject: Re: Performance issues - huge amount of AVC misses
Date: Tue, 8 Dec 2015 10:05:54 -0500	[thread overview]
Message-ID: <5666F1D2.5010701@redhat.com> (raw)
In-Reply-To: <CAL8PO=3Dy-SFzE_DMA=99YcuK5+LXybUwAJgTBY1QZaODEM5Ew@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6198 bytes --]

How are you defining your dontaudit rules?  It is a bad idea to use the
"-" sign.

dontaudit {domain -nissdomain} self:process kill;

Or something like that causes hundreds (Thousands) of rules to be added. 

If you could somehow clean this up to use an attribute like

dontaudit domainswithoutnis self:process kill

Would add one rule.

On 12/08/2015 09:56 AM, Michal Marciniszyn wrote:
> Hi Dominic, > > while there is quite a lot of dontaudit rules around, the amount
for domains running on this node is not high. Is there any way how to
monitor which rules are loaded and released from the cache? Anything
better than plain aggregated stats? We would bot care about performance
of such monitoring tool if it provides some useful answer. For instance,
is there a way how to use system tap or similar kernel profiling to get
the data? > > I'll do a profiling on how many rules actually apply for
the domains on the node (i.e. use sesearch to find out). If doing so,
does the rule in cache hold whole vector (i.e. A is allowed to do X, Y,
Z on B or is one cache entry A can do X on B)? > > Thanks, > > --michal
> > On Tue, Dec 8, 2015 at 11:44 AM, Dominick Grift
<dac.override@gmail.com <mailto:dac.override@gmail.com>> wrote: >
> On Tue, Dec 08, 2015 at 11:25:40AM +0100, Michal Marciniszyn wrote:
> > Hello,
>
> > we are heavy SELinux shop and we recently run into AVC related
> performance
> > issue. I was trying to find an answer on freenode IRC chat but I was
> sent
> > here by multiple guys. We're running on Scientific Linux 6.6 (upgrade to
> > 6.7 ongoing) and we see this on some of our nodes:
>
> > # cat /selinux/avc/cache_stats
> > lookups hits misses allocations reclaims frees
> > 3976846641 3626568307 350278334 350303465 344833264 346344169
> > 3474274460 3092218096 382056364 382081270 381170512 382671551
> > 2037181411 1655679702 381501709 381527148 380680320 382162477
> > 1943162363 1651603455 291558908 291584892 288099840 289631602
> > 829213467 406079951 423133516 423158604 422311024 423847681
> > 1963015875 1555848944 407166931 407192104 406718592 408227742
> > 3490131033 3117047653 373083380 373108386 372270880 373862706
> > 940880689 549698684 391182005 391207388 390339328 391888374
> > 4098417807 3712068859 386348948 386373592 385604096 387172806
> > 3931378773 3549502965 381875808 381901074 381059904 382628308
>
> > Also we see
>
> > # cat /selinux/avc/hash_stats
> > entries: 499
> > buckets used: 257/512
> > longest chain: 6
>
> > Some times under load we see SELinux consuming about 30% of CPU
> time. There
> > is about 16% of cache misses on these nodes (and sometimes it goes
> as high
> > as 30%). The lates article about the issue is from RHEL 5 times -
> >
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/SELinux_Guide/rhlcommon-section-0102.html
> > . We do not feel this to be too relevant in this case.
>
> > Are there any recommendations on cache sizing for SELinux? We can resize
> > cache to 1024 or 2048 entries, but would this help to resolve the issue?
>
> > I'm attaching seinfo from node with our policy and then for
> comparison from
> > node without any policy.
>
> > With policy:
> > # seinfo
>
> > Statistics for policy file: /etc/selinux/targeted/policy/policy.24
> > Policy Version & Type: v.24 (binary, mls)
>
> >    Classes:            81    Permissions:       238
> >    Sensitivities:       1    Categories:       1024
> >    Types:            4273    Attributes:        295
> >    Users:               9    Roles:              12
> >    Booleans:          234    Cond. Expr.:       274
> >    Allow:          352554    Neverallow:          0
> >    Auditallow:        140    Dontaudit:      321786
> >    Type_trans:      42813    Type_change:        38
> >    Type_member:        48    Role allow:         19
> >    Role_trans:        409    Range_trans:      6421
> >    Constraints:        90    Validatetrans:       0
> >    Initial SIDs:       27    Fs_use:             23
> >    Genfscon:           84    Portcon:           505
> >    Netifcon:            0    Nodecon:             0
> >    Permissives:        91    Polcap:              2
>
> I don't have any useful input but just an unrelated observation: you
> almost have as many dontaudit rules as you have allow rules. I would not
> be surprised if that were to be somehow related.
>
>
>
>
> > Without policy:
>
> > seinfo
>
> > Statistics for policy file: /etc/selinux/targeted/policy/policy.24
> > Policy Version & Type: v.24 (binary, mls)
>
> >    Classes:            81    Permissions:       238
> >    Sensitivities:       1    Categories:       1024
> >    Types:            3926    Attributes:        295
> >    Users:               9    Roles:              12
> >    Booleans:          234    Cond. Expr.:       274
> >    Allow:          320969    Neverallow:          0
> >    Auditallow:        140    Dontaudit:      273256
> >    Type_trans:      41915    Type_change:        38
> >    Type_member:        48    Role allow:         19
> >    Role_trans:        386    Range_trans:      6069
> >    Constraints:        90    Validatetrans:       0
> >    Initial SIDs:       27    Fs_use:             23
> >    Genfscon:           84    Portcon:           479
> >    Netifcon:            0    Nodecon:             0
> >    Permissives:        91    Polcap:              2
>
>
> > Any help or guidance would be very much appreciated, if there is more
> > in-depth info needed I'll be more than happy to provide it.
>
> > Yours sincerely,
>
> > Michal Marciniszyn
> > Manager - SW Engineering
> > GoodData
>
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov>
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov
> <mailto:Selinux-leave@tycho.nsa.gov>.
> > To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov <mailto:Selinux-request@tycho.nsa.gov>.
>
>
> > > > > _______________________________________________ > Selinux
mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to
Selinux-leave@tycho.nsa.gov. > To get help, send an email containing
"help" to Selinux-request@tycho.nsa.gov.



[-- Attachment #2: Type: text/html, Size: 9169 bytes --]

  reply	other threads:[~2015-12-08 15:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08 10:25 Performance issues - huge amount of AVC misses Michal Marciniszyn
2015-12-08 10:44 ` Dominick Grift
2015-12-08 14:56   ` Michal Marciniszyn
2015-12-08 15:05     ` Daniel J Walsh [this message]
2015-12-08 15:10     ` Dominick Grift
2015-12-08 15:35     ` Stephen Smalley
2015-12-08 16:21       ` Michal Marciniszyn
2015-12-08 16:29         ` Dominick Grift
2015-12-08 17:06         ` Stephen Smalley
2015-12-08 15:29 ` Stephen Smalley
2015-12-08 16:16   ` Michal Marciniszyn
2015-12-09 10:07 ` Milos Malik
2015-12-09 10:19   ` Michal Marciniszyn
2015-12-09 13:15     ` Michal Marciniszyn
2015-12-09 15:05       ` Stephen Smalley
2015-12-09 16:07         ` Joe Nall
2015-12-09 17:07           ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5666F1D2.5010701@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=michal.marciniszyn@gooddata.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.