On Wed, 2017-06-21 at 10:12 -0700, Bill D wrote:
> On 06/21/2017 09:23 AM, Stephen Smalley wrote:
>
> > On Wed, 2017-06-21 at 08:58 -0700, Bill D wrote:
> > > Hello,
> > >
> > > Is it possible to enforce directory read/write/execute control
> > > using
> > > categories?
> > >
> > > For example, using a category, I would like Linux users assigned
> > > to
> > > that
> > > category to have read/write/execute rights to directory /opt/foo.
> > >
> > > Other Linux users that do not have that category assigned should
> > > not
> > > have read/write/execute access to /opt/foo
> > >
> > > I know this can be done with normal DAC procedures using groups
> > > and/or
> > > file permission tools such as chmod and chown.
> > >
> > > And I also know that it can done with SELinux TE (i.e create an
> > > SELinux
> > > security policy)
> > >
> > > But can it be done by using just categories?
> >
> > Yes, that is how sandbox, libvirt, docker, and other tools isolate
> > sandboxes, VMs, containers, etc. And Android uses it for user
> > isolation and potentially app isolation in the future. Categories
> > are
> > suitable when your primary goal is isolation.
> >
> > In Fedora, you would need to mark the user domains as MCS
> > constrained
> > since that is no longer the default. Depending on your particular
> > goals, you might need to revise the MCS constraints, but they may
> > be
> > sufficient as is.
>
> Thank you for the information. I am using RHEL 6.9 and CentOS 6.9.
>
> Any pointers on how to mark the user domains as MCS constrained and
> how
> to view the existing MCS constraints for verification?
Didn't Philip Seeley provide instructions for using categories in the
earlier discussion of controlling execution of Java JAR files?
Looks like RHEL6 defined mcs_untrusted_proc(), while modern Fedora
defines mcs_constrained() (in
/usr/share/selinux/devel/include/kernel/mcs.if). So, if you wanted to
just use user_t for the users, you would do something like:
# Make user_t MCS constrained.
$ cat mcsconstrained.te
require {
type user_t;
}
# NB: use mcs_constrained() if on Fedora or RHEL 7.
mcs_untrusted_proc(user_t)
# Build and install the above policy module.
$ make -f /usr/share/selinux/devel/Makefile mcsconstrained.pp
$ semodule -i mcsconstrained.pp
# Define a SELinux user that is authorized only for category 0.
$ semanage user -a -R user_r -rs0:c0 c0user_u
# Define a SELinux user that is authorized only for category 1.
$ semanage user -a -R user_r -rs0:c1 c1user_u
# Add a user with category 0 access.
$ useradd -Z c0user_u jack
# Add a user with category 1 access.
$ useradd -Z c1user_u mary
# Restrict /opt/foo to category 1 users.
$ semanage fcontext -a -t usr_t -r s0:c1 "/opt/foo(/.*)?"
$ restorecon -RF /opt/foo
Then login as jack and see if you can access /opt/foo, and ditto for
mary.
I suspect you are better off testing to confirm correct operation than
trying to read the constraints, but if you really want them, you can
see a version disassembled from binary policy via seinfo --constrain,
or can just download the .src.rpm for selinux-policy and extract the
mcs file from it. Looks like RHEL6 did not yet support attribute
preservation in constraints, and still displayed them in postfix form,
so the seinfo --constrain output isn't very human-friendly (it has
since improved).
_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
