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] [thread-next>] [day] [month] [year] [list]
Message-ID: <4747C003.3070709@kernel.org>
Date:	Fri, 23 Nov 2007 22:09:07 -0800
From:	Andrew Morgan <morgan@...nel.org>
To:	casey@...aufler-ca.com
CC:	Stephen Smalley <sds@...ho.nsa.gov>,
	"Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...r.kernel.org,
	chrisw@...s-sol.org, darwish.07@...il.com, jmorris@...ei.org,
	method@...icmethod.com, paul.moore@...com,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch
 added to -mm tree

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I believe it was you who once eloquently observed that, at its heart,
the POSIX (sic) capabilities model was all about providing a mechanism
for overriding the prevailing security policy (be it MAC or DAC or
whatever) in a defined way.

Casey Schaufler wrote:
> Now I know that there are lots of people who don't share my
> views on granularity, but I have lots of experiance with this
> and the cases where it actually makes sense to break the MAC
> capabilities up are rare.
> 
> That's my going in position, at any rate. I'm always open to
> finding out why I'm wrong.

Its not so much why you are wrong, as being clear that we're not using a
generic name and inadvertently limiting ourselves to a SMACK-like model...

It feels to me as if a MAC "override capability" is, if true to its
name, extra to the MAC model; any MAC model that needs an 'override' to
function seems under-specified... SELinux clearly feels no need for one,
and browsing through your SMACK patch, there are many instances where
this capability is used as an convenience privileged override. However,
in other situations, it appears as if the capability is required for
basic SMACK operations to succeed.

My sense is that there is a case to be made for: CAP_MAC_ADMIN and
CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or
whatever MAC supports it) requires privilege to perform a privileged MAC
operation, and the latter for saying "OK, I'm without a paddle but need
one" (or words to that effect).

Cheers

Andrew

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHR8AA+bHCR3gb8jsRAqY/AJsGI56TDQyBD42LCovpJTYHkaL0pQCdHM5S
kk5v2O4ohY2O0z93JNdKVBY=
=dbQn
-----END PGP SIGNATURE-----
-
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