Re: libsemanage.semanage_install_active: error during semodule -n -v -b base.pp -s refpolicy

[Vikram Ambrose <Vikram.Ambrose@windriver.com>]

Stephen Smalley wrote:
> On Fri, 2008-06-13 at 15:11 -0400, Vikram Ambrose wrote:
>   
>> Joshua Brindle wrote:
>>     
>>> Vikram Ambrose wrote:
>>>   
>>>       
>>>> Stephen Smalley wrote:
>>>>     
>>>>         
>>>>> On Thu, 2008-06-12 at 14:51 -0400, Vikram Ambrose wrote:
>>>>>  
>>>>>       
>>>>>           
>>>>>> Stephen Smalley wrote:
>>>>>>    
>>>>>>         
>>>>>>             
>>>>>>> On Thu, 2008-06-12 at 13:57 -0400, Vikram Ambrose wrote:
>>>>>>>        
>>>>>>>           
>>>>>>>               
>>>>>>>> Stephen Smalley wrote:
>>>>>>>>            
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> On Thu, 2008-06-12 at 13:35 -0400, Vikram Ambrose wrote:
>>>>>>>>>                  
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>>> Stephen Smalley wrote:
>>>>>>>>>>                        
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>>>> On Thu, 2008-06-12 at 10:43 -0400, Vikram Ambrose wrote:
>>>>>>>>>>>                                
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>>>> During the "make load" procedure with refpolicy, the semodule
>>>>>>>>>>>> command fails, so I tried it manually and I see this error.
>>>>>>>>>>>>
>>>>>>>>>>>> root@ubuntu:/home/vikram/refpolicy-ac# semodule -b
>>>>>>>>>>>> /usr/share/selinux/refpolicy/base.pp -s refpolicy -v -n
>>>>>>>>>>>> Attempting to install base module
>>>>>>>>>>>> '/usr/share/selinux/refpolicy/base.pp':
>>>>>>>>>>>> Ok: return value of 0.
>>>>>>>>>>>> Committing changes:
>>>>>>>>>>>> libsemanage.semanage_install_active: setfiles returned error
>>>>>>>>>>>> code 1. (No such file or directory).
>>>>>>>>>>>>                                         
>>>>>>>>>>>>                     
>>>>>>>>>>>>                         
>>>>>>>>>>> whereis setfiles
>>>>>>>>>>>
>>>>>>>>>>>                                 
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>> setfiles and the rest of the SELinux "toolchain" was all built
>>>>>>>>>> from svn and placed into /hone/testing/root
>>>>>>>>>> root's environment has PATH that contains /home/testing/root/bin
>>>>>>>>>> as well as LD_LIBRARY_PATH to /home/testing/root/lib
>>>>>>>>>>
>>>>>>>>>> Does libsemanage have a hard coded path to setfiles?
>>>>>>>>>>                         
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>> Yes, although it can be overridden via /etc/selinux/semanage.conf.
>>>>>>>>> Add something like:
>>>>>>>>> [setfiles]
>>>>>>>>> path = /path/to/setfiles
>>>>>>>>> [end]
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> I just noticed the hard coded path in conf-parser.y
>>>>>>>> Is there a way of doing the above with a generic rule to all of the
>>>>>>>> selinux toolchain and not specifically to "setfiles" as shown above?
>>>>>>>>             
>>>>>>>>             
>>>>>>>>                 
>>>>>>> Not presently; it wasn't really intended for an alternate root
>>>>>>> mechanism
>>>>>>> (and apparently doesn't work for it anyway, as you have found).
>>>>>>>
>>>>>>>         
>>>>>>>           
>>>>>>>               
>>>>>> And specifying each and every tool individual is not possible i suppose?
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> There are only two helpers that are executed by default, setfiles and
>>>>> load_policy, and you can specify them both, using the same syntax but
>>>>> different section keyword.
>>>>>
>>>>>  
>>>>>       
>>>>>           
>>>>>>>> ...
>>>>>>>> Adding that to semanage.conf produce an almost obvious error "
>>>>>>>> error while loading shared libraries: libsepol.so.0: cannot open
>>>>>>>> shared object file: No such file or directory"
>>>>>>>>
>>>>>>>> what sort of environment is libsemanage using to execute setfiles?
>>>>>>>> libsepol and friends are in LD_LIBRARY_PATH
>>>>>>>>             
>>>>>>>>             
>>>>>>>>                 
>>>>>>> Ah, semanage_exec_prog() passes a NULL environ to execve().
>>>>>>>
>>>>>>>         
>>>>>>>           
>>>>>>>               
>>>>>> Can this be rectified?
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Even if we changed the code, the policy normally won't allow passing of
>>>>> LD_LIBRARY_PATH and the like across a domain transition (noatsecure
>>>>> permission to disable setting of AT_SECURE auxv flag), and setfiles and
>>>>> load_policy typically run in their own domains.  Although you can
>>>>> certainly customize policy and the code for your particular needs.
>>>>>
>>>>>  
>>>>>       
>>>>>           
>>>>>>> I think this takes us to the "run it in a chroot environment" scenario
>>>>>>> if you don't want to install the libraries and programs to your system
>>>>>>> directories.  I'm not entirely sure what your goal is here though - you
>>>>>>> seem ok with installing the policy files to system directories.
>>>>>>>         
>>>>>>>           
>>>>>>>               
>>>>>> Your last remark there is rather confusing to me. You seem to suggest
>>>>>> that "installing the policy files to system directories" is an option
>>>>>> I have been given, and as such chosen to do so. To my knowledge the
>>>>>> entire toolchain is hard coded to /etc/selinux and as such not
>>>>>> possible to provide a /different/syconfig/path. How is it that I go
>>>>>> about installing selinux and its configuration to a non "system
>>>>>> directory", yet "system wide" path such as /security or /selinux or
>>>>>> /seconfig etc..?
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Well, yes, that's true.  Running it chroot'd is the only way right now
>>>>> to do that.  Which would also resolve your problem with setfiles.
>>>>>
>>>>> The other approach would be to change libselinux to support an alternate
>>>>> root setting via some mechanism, but we have to be careful to not give
>>>>> undue influence to callers where it isn't warranted, of course.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> I added extern char **environ, and passed in environ to execve,  i also
>>>> added some printfs to see what was being passed into setfiles...
>>>>
>>>> root@ubuntu:/home/vikram/refpolicy-ac# semodule -b
>>>> /usr/share/selinux/refpolicy/base.pp -s refpolicy -v
>>>> Attempting to install base module '/usr/share/selinux/refpolicy/base.pp':
>>>> Ok: return value of 0.
>>>> Committing changes:
>>>> e->path=/home/vikram/root/bin/setfiles
>>>> arg[0] = /home/vikram/root/bin/setfiles
>>>> arg[1] = (null)
>>>> usage:  /home/vikram/root/bin/setfiles [-dnpqvW] [-o filename] [-r
>>>> alt_root_path ] spec_file pathname...
>>>> usage:  /home/vikram/root/bin/setfiles -c policyfile spec_file
>>>> usage:  /home/vikram/root/bin/setfiles -s [-dnqvW] [-o filename ] spec_file
>>>> libsemanage.semanage_install_active: setfiles returned error code 1.
>>>>
>>>> Why is setfiles being passed no arguments?
>>>>
>>>>     
>>>>         
>>> you need to add:
>>>
>>> args = -q -c $@ $<
>>>
>>> to the setfiles block in semanage.conf
>>>
>>>   
>>>       
>> could execve be changed to execvp? this way a hard coded path is not 
>> necessary.
>> I can write a patch?
>>     
>
> But then the caller can influence the path and the environment.
> And that presumes that setfiles and load_policy will always be in the
> path of the caller of libsemanage.
>
>   
understood. however the scope of the application's capabilities are 
limited by the user's unix permissions right? ie a regular user can make 
his own policy and store it in his home directory, maybe even with a 
hacked version of semodule, but at the end of the day the policy cannot 
be put into kernel memory by a regular user. Well thats how i understand 
it as.
> You can certainly patch your local copy of it.   Or run it in a chroot.
> Not clear what the argument is for making it an upstream change.
>
>   
Could i make a formal request? Is there another list for that? Or should 
i just start another thread on this list?

thanks.


-- 
Vikram Ambrose | Linux Products Division | WindRiver Corporation


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