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. 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. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
