On Thu, 2006-09-28 at 11:09 -0400, Linda Knippers wrote: > Paul Moore wrote: > > Daniel J Walsh wrote: > > > >>Linda Knippers wrote: > >> > >> > >>>Are only users cleared to SystemHigh supposed to be able to see translated > >>>labels? > >>> > >>>That seems to be the way it works right now with mcstransd. The unix > >>>domain socket between libselinux and mcstransd is SystemHigh so while > >>>commands (ls -Z) run on behalf of a regular user (default SystemLow) > >>>try to translate the labels and can write the request to the socket > >>>but the daemon can't send the response. > >>> > >>>For example, this works: > >>>[EMAIL PROTECTED] ~]# ls -lZd /bin > >>>drwxr-xr-x root root system_u:object_r:bin_t:SystemLow /bin > >>> > >>>This doesn't: > >>>[EMAIL PROTECTED] ~]$ ls -lZd /bin > >>>drwxr-xr-x root root system_u:object_r:bin_t:s0 /bin > >>> > >>> > >> > >>This is broken. I am not sure how to handle this? I have changed it > >>back to SystemLow-SystemHigh > >>which allows it to work properly but I think we need some constraints to > >>prevent someone from getting translations at a higher level then they > >>are authorized for. > > > > > > The translation daemon is a trusted program, yes? If so, could we have > > it do a getpeercon() call to determine the context of the app requesting > > the translation and then do a permissions check to see if the returned > > translation is allowed? At first glance this seems easier than some of > > the alternatives ... > > > > I was looking at that too. I think the daemon already gets that information > (it has a get_peer_con() function) so perhaps all that's missing is the > permission check.
Yes, and that would just be an avc_has_perm() call on the pair of contexts. BTW, as I've previously noted, it should be using getpeercon(3), not getpidcon(3). -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
