On Thu, 2006-04-13 at 08:36 +0100, Paul Howarth wrote: > Is it possible to create new context types in a loadable module? Yes. Just declare them outside of a requires block (requires blocks are just for symbols that your module requires to be defined by the base or another module, not for symbols it defines itself). > Here's why I ask: > > I'm trying to use mock to build packages on FC5 targeted at older > distributions, like Red Hat 8 for instance (more on mock at > http://fedoraproject.org/wiki/Legacy/Mock and > http://fedoraproject.org/wiki/Projects/Mock). What mock basically does > is to create a chroot with a build environment for the target > distribution and runs a regular rpm build within that chroot, pulling in > the other distro's binaries, shared libraries, etc. > > Mock's approach to SELinux is simple: it loads a dummy libselinux that > effectively turns it off. Not likely to work under any policy other than targeted. Dummy libselinux can only turn off userland SELinux processing; it wouldn't affect the kernel enforcement mechanism, so the process would still be subjected to permission checks and a failure to transition properly due to the disabled userland code could still lead to denials. > However, with FC5, this no longer seems to be enough. The memory tests > don't like loading ancient DSO's that don't have separate stack segments > and so some builds fail with execmod errors. I tried using semanage to > set the default context for .so.* files under the chroot to > textrel_shlib_t but although restorecon targeted those files properly, > the contexts weren't set properly within the chrooted build (would I > have to remove the chroot prefix in the semanage call to get that to > work? it's not something I want to do as I'll get the wrong contexts on > files in the host system that way). rpm likely doesn't even try setting the contexts on the files because the dummy libselinux is likely telling it that SELinux isn't enabled (via is_selinux_enabled() < 0). In fact, that happens anyway under a chroot if you don't mount proc under it (and you also typically need selinuxfs as well). rpm --root has similar problems which no one has yet resolved. > So, my idea was to define everything under my chroot as a new type, > mock_root_t, and then have a module like this: > > module mock 0.2; > > require { > class file execmod; > > type unconfined_t; > type mock_root_t; > }; Move the mock_root_t type decl outside of the requires block. > allow unconfined_t mock_root_t:file execmod; > > However, I can't load this module using semodule because mock_root_t > doesn't exist. So is there a way of defining a new type in a module? Yes, as above. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
