On Wed, 2007-08-08 at 20:28 -0400, David-Alexandre Davidson wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-08-02 at 23:14 -0400, David-Alexandre Davidson wrote:
> >
> > > On fedora 7, lastest selinux strict policy.
> > >
> > > I have written a selinux module which go through a domain transition
> > > when executing a file on a nfs mount (labeled nfs_t)
> > > However the transition never occurs. and I get a : denied
> > > execute_no_trans on nfs_t files .
> > >
> > > In order to find the source of the problem I have taken a file with the
> > > exact same context outside of the nfs mount and the transition work fine.
> > >
> > > Here is the related part of my module:
> > >
> > > domain_auto_trans(custom_trans_t,nfs_t,i_custom_t);
> > > allow custom_trans_t nfs_t:file rx_file_perms;
> > > allow custom_trans_t nfs_t:dir r_dir_perms;
> > >
> > >
> > > Here are the details on the nfs share:
> > >
> > > file executed:
> > > -rwxrwxr-x vu20003 vg20003 system_u:object_r:nfs_t
> > > /home/usera/var/bin/testphp.app
> > >
> > > result:
> > > type=AVC msg=audit(1186108700.494:230294): avc: denied {
> > > execute_no_trans } for pid=5969 comm="custom-app" name="testphp.app"
> > > dev=0:18 ino=269058250 scontext=system_u:system_r:custom_trans_t:s0
> > > tcontext=system_u:object_r:nfs_t:s0 tclass=file
> > >
> > >
> > > Running the same program and executing an identical file outside the nfs
> > > share: (I labelled manually to match)
> > >
> > > file executed:
> > > -rwxrwxr-x vu20003 vg20003 system_u:object_r:nfs_t
> > > /testphp.app
> > >
> > > result:
> > > transition is made to context i_custom_t , nothing is audited
> > >
> > >
> > > Any idea what can cause this difference ? I don't believe this behavior
> > > is normal. By the way, if I allow the execute_no_trans on nfs_t, the
> > > file gets executed just fine but without the expected transition...
> > >
> > > Any help would be much appreciated !
> > >
> >
> > If the filesystem is mounted nosuid, then SELinux domain transitions on
> > it are also disabled. Not as flexible as we might like, but a
> > conservative approach. Rationale is that if you didn't trust the
> > filesystem in the first place for suid binaries, then you likely don't
> > trust it for domain entrypoints either.
> >
> >
> Yes that's the case, my filesystem is mounted nosuid.
> Luckily it was not a necessity, but rather because the suid feature is
> not required on those files.
> I will change my mount settings, thanks a lot for your help !
Hmm...that makes me uneasy. We don't want to weaken your security, and
mounting nosuid is a prudent measure when possible. This issue has come
up before, but never been run to ground.
Alternatives to disabling domain transitions upon nosuid would be:
- introduce our own separate mount option for this purpose (notrans or
similar). However, this would require the admin to be explicitly aware
of SELinux, and he might not think of it when he wants to treat a
filesystem as untrusted.
- assume that the admin will always use a context mount when the
filesystem is untrusted, thereby overriding any contexts on the
filesystem with one that is not an entrypoint.
- perform an associate check between the inode label and the superblock
label upon d_instantiate and remap the inode to unlabeled if the
association is not permitted, so that one can mount a filesystem with
fscontext= and thereby prohibit privileged entrypoint types from being
taken from it while still using other types from it.
Should likely be added to the kernel todo list.
> By the way, is there plans to ever add configuration options to the
> selinux config file ? I believe it would be a natural way to specify
> various selinux behavior in case like this one, where the policy
> itself isn't concerned. In my particular situation I am forcing a
> domain transition in order to isolate everything that is executed on
> the mounted filesystem, in the same domain. An execution without
> transition would be a greater security risk.
Well, it could be controllable via a /selinux setting I suppose, and
that could be initially set based on /etc/selinux/config.
--
Stephen Smalley
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
