From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <446F8E7C.8010503@gentoo.org> Date: Sat, 20 May 2006 17:47:40 -0400 From: Joshua Brindle MIME-Version: 1.0 To: Stephen Smalley CC: russell@coker.com.au, Daniel J Walsh , Steve Grubb , SE Linux Subject: Re: Real simple cache that removes most of the lookups in mcstrans References: <446AFED3.9010800@redhat.com> <446B3B51.1060703@redhat.com> <446B3E11.6040302@gentoo.org> <200605192333.01639.russell@coker.com.au> <446DCD4C.6000303@gentoo.org> <1148047642.25168.107.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1148047642.25168.107.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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.