Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
On Tue, 16 Oct 2007 16:41:59 -0500 Serge E. Hallyn [EMAIL PROTECTED] wrote: To properly test this the libcap code will need to be updated first, which I'm looking at now... This seems fairly significant. I asusme that this patch won't break presently-deployed libcap? - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
Quoting Andrew Morton ([EMAIL PROTECTED]): On Tue, 16 Oct 2007 16:41:59 -0500 Serge E. Hallyn [EMAIL PROTECTED] wrote: To properly test this the libcap code will need to be updated first, which I'm looking at now... This seems fairly significant. I asusme that this patch won't break presently-deployed libcap? It will break libcap. And I'm not sure of the right way to address it. So I was hoping to hear some ideas from Andrew Morgan, Chris Wright, and Kaigai. We can introduce new capget64() and capset64() calls, and have capget() return -EINVAL or -EAGAIN if a high bit would be needed to accurately get the task's capabilities. Or we can require a new libcap, since capget and capset aren't required for most day-to-day function anyway. I guess now that I've written this out, it seems pretty clear that capget64() and capget64() are the way to go. Any objections? thanks, -serge - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
--- Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Andrew Morton ([EMAIL PROTECTED]): On Tue, 16 Oct 2007 16:41:59 -0500 Serge E. Hallyn [EMAIL PROTECTED] wrote: To properly test this the libcap code will need to be updated first, which I'm looking at now... This seems fairly significant. I asusme that this patch won't break presently-deployed libcap? It will break libcap. And I'm not sure of the right way to address it. So I was hoping to hear some ideas from Andrew Morgan, Chris Wright, and Kaigai. We can introduce new capget64() and capset64() calls, and have capget() return -EINVAL or -EAGAIN if a high bit would be needed to accurately get the task's capabilities. Or we can require a new libcap, since capget and capset aren't required for most day-to-day function anyway. I guess now that I've written this out, it seems pretty clear that capget64() and capget64() are the way to go. Any objections? Not from me. Thank you. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
On Wed, 17 Oct 2007 21:59:20 -0500 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Andrew Morton ([EMAIL PROTECTED]): On Tue, 16 Oct 2007 16:41:59 -0500 Serge E. Hallyn [EMAIL PROTECTED] wrote: To properly test this the libcap code will need to be updated first, which I'm looking at now... This seems fairly significant. I asusme that this patch won't break presently-deployed libcap? It will break libcap. yikes, dropped! And I'm not sure of the right way to address it. So I was hoping to hear some ideas from Andrew Morgan, Chris Wright, and Kaigai. We can introduce new capget64() and capset64() calls, and have capget() return -EINVAL or -EAGAIN if a high bit would be needed to accurately get the task's capabilities. Or we can require a new libcap, since capget and capset aren't required for most day-to-day function anyway. I guess now that I've written this out, it seems pretty clear that capget64() and capget64() are the way to go. Any objections? Sounds sane. New syscalls are cheap and it's clear separation. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Version 8 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
On Tue, Oct 16, 2007 at 09:17:40PM -0700, Casey Schaufler wrote:
At random:
+static int smack_netlabel(struct sock *sk)
+{
+ static int initialized;
+ struct socket_smack *ssp = sk-sk_security;
+ struct netlbl_lsm_secattr secattr;
+ int rc = 0;
+
+ if (!initialized) {
+ smk_cipso_doi();
+ initialized = 1;
+ }
And just what happens if another task calls the same while we are
blocked on allocation in smk_cipso_doi()?
Another problem is your handling of smk_known - you add to head under
mutex; fine. However, you read without one _and_ have no barriers
in initializing new list entries.
Think what happens if CPU1 adds to list and CPU2 sees write to smk_known
*before* it sees write to -smk_next. We see a single-element list and
we'll be lucky if that single entry won't be FUBAR.
-
To unsubscribe from this list: send the line unsubscribe
linux-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Version 8 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
On Thu, Oct 18, 2007 at 05:57:05AM +0100, Al Viro wrote: On Tue, Oct 16, 2007 at 09:17:40PM -0700, Casey Schaufler wrote: Think what happens if CPU1 adds to list and CPU2 sees write to smk_known *before* it sees write to -smk_next. We see a single-element list and we'll be lucky if that single entry won't be FUBAR. While we are at it, what protects smack_cipso_count? - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote: I guess now that I've written this out, it seems pretty clear that capget64() and capget64() are the way to go. Any objections? How is capget64() different from capget() that supports 2 different header-versions (I thought that was the whole point of the versioned, rather opaque interface)? I don't object to a new syscall, but I don't see why it's required to avoid breaking libcap. thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
