On Thu, 2006-04-13 at 08:20 -0400, Stephen Smalley wrote:
> On Thu, 2006-04-13 at 08:08 -0400, Stephen Smalley wrote:
> > > 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.
>
> Oh, and you should really do it like this (similar to my prior
> discussion about creating a policy module for the samba issue):
> $ mkdir mock
> $ cd mock
> $ vi mock.te
> i(nsert)
> policy_module(mock, 0.2)
>
> require {
> type unconfined_t;
> };
>
> type mock_root_t;
> files_type(mock_root_t) # allow this type to be used for files
> allow unconfined_t mock_root_t:file execmod;
> :wq
Two key points about the above module source vs. what you posted:
1) Use policy_module macro/interface rather than just a direct module
decl - this needs to be updated in all refpolicy documentation. It
brings in additional content including require statements for the kernel
classes and permissions so that you don't have to do that.
2) When you define a new type, you have to assign it appropriate
attributes, and in refpolicy, this is done by using an appropriate
interface like files_type or domain_type. Interfaces are located
under /usr/share/selinux/devel/include and are documented
under /usr/share/doc/selinux-policy-x.y.z/html as well as on the
refpolicy sourceforge site (http://serefpolicy.sf.net).
> $ touch mock.if mock.fc
> $ make -f /usr/share/selinux/devel/Makefile
> $ su
> # semodule -i mock.pp
>
> Chad and Dan, can we get this kind of example (and/or the prior one I
> created for the samba issue) added to the FAQ? Otherwise, people don't
> have good examples to follow.
--
Stephen Smalley
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
