All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Sungbae Yoo <sungbae.yoo@samsung.com>,
	"'Lukasz Pawelczyk'" <l.pawelczyk@samsung.com>,
	"'James Morris'" <james.l.morris@oracle.com>,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] Smack: replace capable() with ns_capable()
Date: Tue, 28 Jul 2015 09:11:02 -0700	[thread overview]
Message-ID: <55B7A996.8010704@schaufler-ca.com> (raw)
In-Reply-To: <20150728150636.GA1656@mail.hallyn.com>

On 7/28/2015 8:06 AM, Serge E. Hallyn wrote:
> On Tue, Jul 28, 2015 at 07:36:30AM -0700, Casey Schaufler wrote:
>> On 7/26/2015 6:27 PM, Sungbae Yoo wrote:
>>> So, Do you agree to allow the process to change its own labels?
>> No. This requires CAP_MAC_ADMIN. Smack is mandatory access control.
>> Being in a namespace (as they are implemented today) is not sufficient.
> "requires CAP_MAC_ADMIN" should probably read "requires
> CAP_MAC_ADMIN against initial user namespace."  Any unprivileged
> user can unshare a user_ns and get CAP_MAC_ADMIN.

As you say. Since the inode's xattrs are common you need
privilege relative to the initial namespace.

>
> I'm terribly sorry I'm not yet caught up on the smack-lsm thread.
> But intuitively I'd think that you'd want a way for smack policy
> to say "this label is allowed to create a user-ns which will be
> allowed to CAP_MAC_ADMIN", so then smack_capable() can use that
> information to cleanly deny CAP_MAC_ADMIN in namespaces.
>
> -serge
>


      reply	other threads:[~2015-07-28 16:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-24 11:26 [PATCH] Smack: replace capable() with ns_capable() Sungbae Yoo
2015-07-24 11:40 ` Lukasz Pawelczyk
2015-07-25 16:59   ` Casey Schaufler
2015-07-27  1:27   ` Sungbae Yoo
2015-07-27  8:52     ` Lukasz Pawelczyk
2015-07-28 14:36     ` Casey Schaufler
2015-07-28 15:06       ` Serge E. Hallyn
2015-07-28 16:11         ` Casey Schaufler [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55B7A996.8010704@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=james.l.morris@oracle.com \
    --cc=l.pawelczyk@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=sungbae.yoo@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.