linux-kernel - Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

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]

Date:	Mon, 08 Oct 2007 12:47:43 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	casey@...aufler-ca.com
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	Kyle Moffett <mrmacman_g4@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Bill Davidsen <davidsen@....com>,
	James Morris <jmorris@...ei.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

Casey Schaufler <casey@...aufler-ca.com> writes:

> --- "Eric W. Biederman" <ebiederm@...ssion.com> wrote:
>
>
>> Likely.  Until we have a generalized LSM interface with 1000 config
>> options like netfilter I don't expect we will have grounds to talk
>> or agree to a common user space interface.  Although I could be
>> wrong.
>
> Gulp. I know that many of you are granularity advocates, but I
> have to say that security derived by tweeking 1000 knobs so that
> they are all just right seems a little far fetched to me. I see
> it as poopooing the 3rd and most important part of the reference
> monitor concept, "small enough to analyze". Sure, you can analyse
> the 1000 individual checks, but you'll never be able to describe
> the system behavior as a whole.

Agreed.  I wasn't thinking 1000 individual checks but 1000 different
capabilities, could be either checks or actions, basically fundamental
different capabilities.  Things like CIPSO, or the ability to store a
security label on a file.  I would not expect most security policies
to use most of them.  Neither do I expect Orange book security to
necessarily be what people want to achieve with the LSM.   But I
haven't looked at it enough detail to know how things should be
factored, in this case I was simply extrapolating from the iptables
experience where  we do have a very large number of options.

The real point being is that I would be surprised if we could come
to an agreement of a common user space API when we can't agree on how
to compile all of the security modules into the kernel and have them
play nice with each other. 

Assuming we can achieve security modules playing nice with each other
using a mechanism similar to iptables, then what needs to be evaluated
is the specific table configuration we are using on the system, not
the full general set of possibilities.  Further I expect that for the
truly security paranoid we want the option to disable further table
changes after the tables have been configured.

On another side personally I don't see where the idea comes from that
you can describe system behavior as a whole without analyzing the
entire kernel.  Has there been work on a sparse like tool that I'm
not aware of to ensure the we always perform the appropriate security
checks on the user/kernel interface boundary?

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