linux-kernel - Re: [PATCH 3/4] capability: Create a new capability CAP

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: <20130320144110.GF17274@redhat.com>
Date:	Wed, 20 Mar 2013 10:41:10 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	James Morris <jmorris@...ei.org>
Cc:	Casey Schaufler <casey@...aufler-ca.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, zohar@...ux.vnet.ibm.com,
	dmitry.kasatkin@...el.com, akpm@...ux-foundation.org,
	ebiederm@...ssion.com, serge@...lyn.com, morgan@...nel.org,
	Matthew Garrett <matthew.garrett@...ula.com>
Subject: Re: [PATCH 3/4] capability: Create a new capability CAP_SIGNED

On Wed, Mar 20, 2013 at 04:07:58PM +1100, James Morris wrote:
> On Fri, 15 Mar 2013, Casey Schaufler wrote:
> 
> > Capabilities aren't just random attribute bits. They
> > indicate that a task has permission to violate a
> > system policy (e.g. change the mode bits of a file
> > the user doesn't own).
> 
> Casey's right here, as well he should be.
> 

Ok, so how do I go about it (Though I have yet to spend more time
understanding the suggestion in couple of other mails. I will do that
now)

I am not sure why CAP_COMPROMISE_KERNEL(CAP_MODIFY_KERNEL) is any
different. When secureboot is enabled, kernel will take away that
capability from all the processes. So kernel became a decision maker
too whether processes have CAP_COMPROMISE_KERNEL or not based on
certain other factors like secureboot is enabled or not.

If I draw a parallel, then based on certain other factors (binary is
signed and secureboot trust has been extended to this binary), why
can't kernel take a decision to give extra capability to this binary.

In fact instead of new capabiilty, I guess upon successful signature
verification, one could just give CAP_MODIFY_KERNEL to process.

I am just trying to understand better that why capability is not
a good fit here (Especially given the fact that CAP_MODIFY_KERNEL
is making progress and it seems reasonable to me to extend the
secureboot trust to validly signed processes. Like modules, their
signatures have been verified and they should be allowed to modify
kernel).

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