All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	"Andrew G. Morgan" <morgan@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"Hervé Guillemet" <herve@guillemet.org>,
	"Casey Schaufler" <casey@schaufler-ca.com>
Subject: Re: [PATCH] fix namespaced fscaps when !CONFIG_SECURITY
Date: Sun, 29 Nov 2020 15:15:42 -0600	[thread overview]
Message-ID: <20201129211542.GA5227@mail.hallyn.com> (raw)
In-Reply-To: <CALQRfL6q8ppuWi3ygY6iqh6SX9pnkVnvJDynTD61K2wUqerahg@mail.gmail.com>

Hi James,

would you mind adding this to the security tree?  (You can cherrypick
from https://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux.git/commit/?h=2020-11-29/fix-nscaps )

thanks,
-serge

On Tue, Nov 17, 2020 at 08:09:59AM -0800, Andrew G. Morgan wrote:
> Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
> 
> 
> On Tue, Nov 17, 2020 at 7:09 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> 
> > Namespaced file capabilities were introduced in 8db6c34f1dbc .
> > When userspace reads an xattr for a namespaced capability, a
> > virtualized representation of it is returned if the caller is
> > in a user namespace owned by the capability's owning rootid.
> > The function which performs this virtualization was not hooked
> > up if CONFIG_SECURITY=n.  Therefore in that case the original
> > xattr was shown instead of the virtualized one.
> >
> > To test this using libcap-bin (*1),
> >
> > $ v=$(mktemp)
> > $ unshare -Ur setcap cap_sys_admin-eip $v
> > $ unshare -Ur setcap -v cap_sys_admin-eip $v
> > /tmp/tmp.lSiIFRvt8Y: OK
> >
> > "setcap -v" verifies the values instead of setting them, and
> > will check whether the rootid value is set.  Therefore, with
> > this bug un-fixed, and with CONFIG_SECURITY=n, setcap -v will
> > fail:
> >
> > $ v=$(mktemp)
> > $ unshare -Ur setcap cap_sys_admin=eip $v
> > $ unshare -Ur setcap -v cap_sys_admin=eip $v
> > nsowner[got=1000, want=0],/tmp/tmp.HHDiOOl9fY differs in []
> >
> > Fix this bug by calling cap_inode_getsecurity() in
> > security_inode_getsecurity() instead of returning
> > -EOPNOTSUPP, when CONFIG_SECURITY=n.
> >
> > *1 - note, if libcap is too old for getcap to have the '-n'
> > option, then use verify-caps instead.
> >
> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1593431
> > Cc: Hervé Guillemet <herve@guillemet.org>
> > Cc: Andrew G. Morgan <morgan@kernel.org>
> > Cc: Casey Schaufler <casey@schaufler-ca.com>
> > ---
> >  include/linux/security.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/security.h b/include/linux/security.h
> > index bc2725491560..39642626a707 100644
> > --- a/include/linux/security.h
> > +++ b/include/linux/security.h
> > @@ -869,7 +869,7 @@ static inline int security_inode_killpriv(struct
> > dentry *dentry)
> >
> >  static inline int security_inode_getsecurity(struct inode *inode, const
> > char *name, void **buffer, bool alloc)
> >  {
> > -       return -EOPNOTSUPP;
> > +       return cap_inode_getsecurity(inode, name, buffer, alloc);
> >  }
> >
> >  static inline int security_inode_setsecurity(struct inode *inode, const
> > char *name, const void *value, size_t size, int flags)
> > --
> > 2.25.1
> >
> >

  parent reply	other threads:[~2020-11-29 21:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17 15:08 [PATCH] fix namespaced fscaps when !CONFIG_SECURITY Serge E. Hallyn
2020-11-17 16:11 ` Andrew G. Morgan
2020-11-20  3:19   ` James Morris
2020-11-20  5:03     ` Andrew G. Morgan
2020-11-17 17:51 ` Casey Schaufler
2020-11-20  3:16 ` James Morris
2020-11-20  3:19 ` James Morris
     [not found] ` <CALQRfL6q8ppuWi3ygY6iqh6SX9pnkVnvJDynTD61K2wUqerahg@mail.gmail.com>
2020-11-29 21:15   ` Serge E. Hallyn [this message]
2020-12-01  2:58     ` James Morris
2020-12-04 15:58       ` Andrew G. Morgan
2020-12-05  0:27         ` James Morris
2020-12-05 17:40         ` Serge E. Hallyn
2020-12-05 17:41           ` Serge E. Hallyn

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=20201129211542.GA5227@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=casey@schaufler-ca.com \
    --cc=herve@guillemet.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=morgan@kernel.org \
    /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.