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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ