Re: [PATCH] libsemanage/semanage - permission check for semanage

[Joshua Brindle <jbrindle@tresys.com>]

Stephen Smalley wrote:
> On Fri, 2006-01-20 at 16:25 -0500, Joshua Brindle wrote:
> 
>>Stephen Smalley wrote:
>>
>>>Better, but a few lingering issues/questions:
>>>1) Running semanage as a non-root user with existing default modes on
>>>the policy module tree yields "SELinux policy is not managed."
>>>So we aren't quite providing the right information to the user yet.
>>>
>>
>>if the user can't stat the module directory how do we know whether or 
>>not it is a managed system?
> 
> 
> Understood, but the message to the user needs to convey that fact, i.e.
> instead of just saying "SELinux policy is not managed", we likely need
> to say "SELinux policy is not managed or the module store is not
> accessible to you."  

sounds good
> 
> We also need to make sure that setsebool continues to do the right thing
> here, as it uses semanage_is_managed() to decide whether it should a)
> abort with an error (if < 0), b) fall back to the libselinux support for
> setting booleans (== 0), or proceed to use the semanage functions for
> setting booleans (> 0).  It looks like this patch is fine in that
> respect since it doesn't change that interface; it should just silence
> the warning we get from libsemanage in (b).  
> 
yes, looking at setsebool it seems correct wrt is_managed. Which warning 
are you speaking of? In is_managed == 0 it uses 
selinux_set_boolean_list() and on success goes to out which destroys the 
handle and returns.

> Trying setsebool as a normal user I get "Could not change active
> booleans:  Permission denied", which seems like a reasonable error
> message for that case.  Only potential concern is that what is really
> happening there is that setsebool is falling back to case (b) and trying
> to directly manipulate booleans via libselinux, and it is only the lack
> of permission to do so that prevents it from proceeding.  So if the
> caller lacked permission to access the module store but had permission
> to directly manipulate booleans (a pathological situation indeed), then
> setsebool could do the wrong thing here.
> 

Hrm.. an interesting problem. How can we determine when the fallback 
should happen? It seems difficult to differenciate the 'not managed' and 
'no permission to see store' cases, which means setsebool can't know 
when to fallback and when not to. I'm not sure there is a solution to 
this problem except to encapsulate access to booleans through 
libsemanage clients, even in the targeted policy, which might not be 
acceptable.

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