Re: [PATCH] Smack: fix domain transfer issues

From: Stephen Smalley
Date: Thu Sep 29 2011 - 10:44:15 EST


On Thu, 2011-09-29 at 16:57 +0300, Jarkko Sakkinen wrote:
> On Thu, 29 Sep 2011, Stephen Smalley wrote:
>
> > On Thu, 2011-09-29 at 11:26 +0300, Jarkko Sakkinen wrote:
> >> MNT_NOSUID should be checked.
> >
> > Doubtful, as Smack and capabilities are completely orthogonal, right?
> > Even for SELinux, the nosuid check is a bit of a nuisance.
>
> What I'm planning to do is to not switch
> domain if filesystem is mounted with nosuid.
> Same logic as prepare_binprm does for suid
> and sgid bits.

I'm not sure that is required since a Smack label change doesn't alter
the allowable capabilities, and doing so will create conflicts for users
who will have to choose between supporting Smack label transitions on a
filesystem and mounting it nosuid. We've seen such issues for SELinux.
Having a separate flag for label transitions would be better.

Also, if it is possible for an exec label to be ignored/overridden, then
you might want to consider an equivalent to the SELinux execute_no_trans
check.

> I've already added death signal clearing to the
> next-to-be-submitted revision of this patch.
> I'm planning to implemented flushing of
> non-permissible files and signals as two separate
> patches later on (in the near future however).

I'd view the lack of equivalents to the transition and entrypoint checks
as more critical, as well as the lack of any control over the
relationship between the file access control label and its exec label.
How can you determine what labels are reachable from a given label? How
can you determine what programs can be used to enter a given label? How
can you determine who can modify a program that can be used to enter a
given label?

--
Stephen Smalley
National Security Agency

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/