linux-kernel - Re: [PATCH] Smack: fix domain transfer issues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1317307446.4079.33.camel@moss-pluto>
Date:	Thu, 29 Sep 2011 10:44:06 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Jarkko Sakkinen <jarkko.sakkinen@...el.com>
Cc:	Casey Schaufler <casey@...aufler-ca.com>,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH] Smack: fix domain transfer issues

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/