Re: MLS dominance check behavior on el7

[Joe Nall]

> On Sep 11, 2018, at 1:29 PM, Stephen Smalley  wrote:
> 
> On 09/11/2018 10:41 AM, Stephen Smalley wrote:
>> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>> mcstrans mcscolor.c also uses the same logic I'd been using to check 
>>> dominance so this too will no longer function as expected on el7. Do you 
>>> any suggestions for doing a 'generic' (one not tied to a specific resource 
>>> class) dominance check in lieu of context contains?
>> You should probably define your own permission with its own constraint to 
>> avoid depending on the base policy's particular constraint definitions.  
>> Certainly for your own code.  For mcstrans, mcscolor probably ought to be 
>> switched to using at least a separate permission in the context class if not 
>> its own class to avoid overloading the meaning with pam_selinux's usage (or 
>> vice versa, but likely harder to change pam_selinux at this point).
>> It is possible to define an entirely new class, its permissions, and its mls 
>> constraints via a CIL module IIUC, without needing to change the base policy.
>> I don't think you can add a permission to an existing class via a CIL module 
>> currently, unfortunately, so you can't just extend the context class without 
>> modifying the base policy.  So it may be easier to define an entirely new 
>> class.
>> The class and permission ought to be specific to the usage.  For example, 
>> mcstrans could have its own class (mcstrans) with its own permissions (e.g. 
>> color_match or color_use or ...) that abstract away the logical check being 
>> performed.  Dominance checks performed for different reasons ought to use 
>> different permissions so that one can distinguish what TE pairs are allowed 
>> them.
>> Your code could likewise define and use its own class and permission.
>> Does that make sense?
> 
> BTW, I noticed there is another permission ("translate") defined in the 
> context class and its constraint is ((h1 dom h2) or (t1 == mlstranslate)).  I 
> would have guessed that it was intended as a front-end service check over 
> what processes could request context translations from mcstrans or what 
> contexts they could translate, but I don't see it being used in mcstrans 
> anywhere.  Is this a legacy thing from early setransd/mcstransd days?  There 
> is a TODO comment in mcstrans process_request() that suggests there was an 
> intent to perform a dominance check between the requester context and the 
> specified context, but that's not implemented.  Appears to be allowed in 
> current policy for all domains to the setrans_t domain itself.

I think 'translate' predates my mcstransd work and dates from the original TCS 
implementation. There is an argument to implement that constraint, but we've 
been operating without it for so long it does not seem worthwhile.

joe



___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: Performance issues - huge amount of AVC misses

[Joe Nall]

This thread motivated me to look at some test boxes. One is seeing about 2k 
misses per second under high load. Raising the cache_threshold to 1024 lowered 
that to 600 misses per second and raising it to 2048 lowered it to 0 with 
occasional bounces to 20-50.

Are there any negatives to raising the cache_threshold?

What is the approximate cost of a miss?

Is there a persistent mechanism to set the cache_threshold? The system is RHEL 
6.6 with custom MLS policy.

joe


> On Dec 9, 2015, at 9:05 AM, Stephen Smalley  wrote:
> 
> On 12/09/2015 08:15 AM, Michal Marciniszyn wrote:
>> Hi,
>> 
>> after increasing the cache, I do not see many reclaims, like couple of
>> them here and there. The cache size had to be increased to 2048 to get
>> ti this state.
>> 
>> # avcstat 15
>> 
>> 537645 537623 22 22 32 32
>> 942916 942912  4  4  0  0
>> 604466 604457  9  9  0  0
>> 451737 451730  7  7 16 16
>> 457669 457669  0  0  0  0
>> 519135 519133  2  2  0  0
>> 517288 517288  0  0  0  0
>> 380376 380376  0  0  0  0
>> 464272 464269  3  3  0  0
>> 531484 531482  2  2  0  0
>>14224221422421  1  1  0  0
>>13809321380932  0  0  0  0
>> 512999 512999  0  0  0  0
>> 
>> 
>> Is it ok if I get longest chain length 13 in hash stats (It was higher
>> in the beginning - 19, but got to 13 after 2 hours)?
> 
> I wouldn't worry about that; it's insignificant compared to the cost of an 
> AVC miss.
> 
> 
> 
> ___
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.