Re: Real simple cache that removes most of the lookups in mcstrans

[Joshua Brindle <method@gentoo.org>]

Stephen Smalley wrote:
> On Fri, 2006-05-19 at 09:51 -0400, Joshua Brindle wrote:
>   
>> Russell Coker wrote:
>>     
>>> If an application such as "ls" gets a copy of the translation data then there 
>>> is no point in writing the library code such that the data can not be 
>>> (easily) displayed a second time.  The information once available is presumed 
>>> to have already been displayed to the user or stored in a way such that it 
>>> can be obtained in another manner.
>>>   
>>>       
>> If that were true we wouldn't revoke access to file descriptors (or 
>> files) after a policy reload.
>>     
>
> Not the same thing.  Revoking data != revoking object capabilities.  The
> data has already leaked.  Revoking the object capability prevents
> reading of _new_ data from the object, and writing of data to the
> object.  But the already read data has already migrated into the state
> of the client.
>   
That is a tricky distinction. AFAIK the servers that do access control 
for translations essentially treat the translation itself as the object 
(by using the untranslated context as the target object with a specific 
object class). I understand that you can't revoke access to the data in 
a file that a program read, only further access to the file. And I know 
that the client can cache the information outside of the library. My 
point is that if the access changes the client potentially won't know 
because the library is transparently caching the information and not 
consulting the server.
>   
>>  And you are still ignoring the case where 
>> the translation actually changes. My worry isn't ls (which is one-shot, 
>> and executes quickly most of the time), _anything_ that uses this 
>> library code now caches the answer and if its a long running process 
>> then it has no way of knowing when translations have changed or access 
>> has been revoked.
>>     
>
> Notifications of changes to the translations make sense for correctness.
> Not so much of an access control issue
Understood, however, if the client is providing a translation service 
for a user (or other application) it should get notification if that 
user/app should no longer be able to see the translation, right? The 
translations are treated like objects in this scheme, unless I'm 
misunderstanding something.

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