[redhat-lspp] Re: mcstransd question

Linda Knippers linda.knippers at hp.com
Mon Oct 2 19:06:38 UTC 2006


Stephen Smalley wrote:
> On Thu, 2006-09-28 at 14:33 -0400, Linda Knippers wrote:
> 
>>Its a little more complicated than that because avc_has_perm() takes
>>you down a path where it wants to translate a context.
>>
>>avc_had_perm() calls avc_has_perm_noaudit() and if the avc_lookup()
>>fails, it calls security_compute_av(), which needs a raw context
>>so it calls back into the translation functions.
>>
>>I think I can make it work by calling security_compute_av_raw()
>>instead but then it doesn't get cached, right?
>>
>>Any other ideas?
> 
> 
> Hmmm..context translation support wasn't properly integrated with the
> userspace AVC.  Logically, I'd expect avc_context_to_sid() and
> avc_sid_to_context() to perform translation, such that
> avc_has_perm_noaudit() would already have the raw contexts available to
> it from the SIDs and be able to directly call security_compute_av_raw()
> internally.  And then one would have avc_context_to_sid_raw() and
> avc_sid_to_context_raw() for programs that didn't want translation at
> all.
> 
> For the translation daemon itself, you might want a libselinux function
> that lets you disable all translations (i.e. set a flag that is checked
> on entry by selinux_trans_to_raw_context() and
> selinux_raw_to_trans_context() and handled in the same manner as the !
> mls_enabled case).  Then the translation daemon could just call any
> libselinux function without needing to worry about accidentally
> triggering a communication to itself.

I threw together a couple of patches.  Is this what you had in mind?

-- ljk


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libselinux.patch
URL: <http://listman.redhat.com/archives/redhat-lspp/attachments/20061002/fc08a92f/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mcstransd.patch
URL: <http://listman.redhat.com/archives/redhat-lspp/attachments/20061002/fc08a92f/attachment-0001.ksh>


More information about the redhat-lspp mailing list