linux-kernel - Re: [RFC v2] security: intoduce ptrace_task_may_access

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:	Mon, 20 Jun 2011 12:50:33 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Serge Hallyn <serge.hallyn@...onical.com>
CC:	Vasiliy Kulikov <segoon@...nwall.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, apparmor@...ts.ubuntu.com,
	"selinux@...ho.nsa.gov Stephen Smalley" <sds@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	Eric Paris <eparis@...isplace.org>,
	John Johansen <john.johansen@...onical.com>,
	kernel-hardening@...ts.openwall.com, serge@...lyn.com
Subject: Re: [RFC v2] security: intoduce ptrace_task_may_access_current

On 06/20/2011 11:00 AM, Serge Hallyn wrote:
> Quoting Eric Paris (eparis@...hat.com):
>> Ahhhh, I feel so unhappy with capability code these days.  Serge can
>> you come to the rescue?  I'm really really starting to dislike the
>> fact that we have lots of code flows that goes
>> kernel->kernel/capablities->LSM->security/capabilities.  Which is a
>> very strange calling convention.  I'd like to stop adding any calls
>> to kernel/capability.c and everything from now on needs to be done
>> with an LSM function named security_*.  I'd really like to see
>> kernel/capabilities stripped back to nothing but syscall handling
>> and move all of has_capability, has_ns_capability, ns_capable,
>> task_ns_capable, and all that crap moved to normal LSM calls.
> 
> I can see why you'd feel that way, but I'd like to hold off on that
> until we get targeted capabilities and VFS user namespace support ironed
> out.  I'm working on it right now (at
> http://kernel.ubuntu.com/git?p=serge/userns-2.6.git;a=summary)
> 
> I certainly do not want the targeted stuff duplicated in every LSM.
> Maybe we can move that stuff into security/security.c though.
> 
> Anyway I'm just coming back after leave, and only ever took a
> quick glance at this patch.  I'll look again.

I'm certainly not asking for you to throw down everything you have to do
and rewrite all of this code!  But I'd like to see a slow move towards
the elimination of kernel/capability.c and wondered if you agreed that
was a good idea.  If so, this can be the first place we start to think
about how to move intelligently to use LSM functions rather than direct
capability calls.  I like the idea that he use the has_* functions
instead of creating new ones in there.

Hopefully you can help guide us on the right path Serge!

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