linux-kernel - Re: [PATCH] sysctl selinux: Don't look at table->de

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: <m14pq9lntk.fsf@ebiederm.dsl.xmission.com>
Date:	Mon, 29 Jan 2007 10:55:51 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	James Morris <jmorris@...ei.org>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>, Andrew Morton <akpm@...l.org>,
	Ingo Molnar <mingo@...e.hu>, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov
Subject: Re: [PATCH] sysctl selinux: Don't look at table->de

James Morris <jmorris@...ei.org> writes:

> On Mon, 29 Jan 2007, Stephen Smalley wrote:
>
>> NAK.  Mapping all sysctls to a single security label prevents any kind
>> of fine-grained security on sysctls, and current policies already make
>> use of the current distinctions to limit access to particular sets of
>> sysctls to particular processes.  As is, I'd expect breakage of current
>> systems running SELinux from this patch, because (confined) processes
>> that formerly only required access to specific sysctl labels will
>> suddenly run into denials on the generic fallback label.
>
> Agreed, 100% NACK.
>
> Please don't just simply remove long-researched & analyzed MAC security 
> which has been in the kernel for years, which is being used in the field 
> for high assurance systems, because you neglected to consider it during a 
> code cleanup.

Please don't shoot the messenger when a weakness is found in your code.
Systems that increase security without worry that their implementation
is correct do not impress me, but I do understand that security has
little to do with correctness and everything to do with making it
_expensive_ for the other guy to do what he isn't supposed to.

This code path was always in the selinux code for when /proc was
compiled out.  I could see no way to preserve it so I removed
it.

Not knowing if it was a problem, or if we needed to do something more
I copied the people who did, at the first available opportunity.
Before this code makes it's way into peoples production systems.

Of course after all of the rants against path based security I was
amazed to find a code path that was using exactly that in selinux.
Equally I'm amazed that all of that long-researched and analysis of
the MAC security has not found these issues where you integrate with
the rest of the linux kernel.

I'm trying to make things correct, and simple and will be happy to
work with you in a way to achieve what you need in a way that does
not conflict with the rest of the kernel.

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/