linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Serge Hallyn <serge.hallyn@canonical.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Eric Paris <eparis@parisplace.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	linux-fsdevel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH] fuse: Only allow read/writing user xattrs
Date: Mon, 8 Oct 2012 08:47:51 -0500	[thread overview]
Message-ID: <20121008134751.GB5351@sergelap> (raw)
In-Reply-To: <87zk3zgoc2.fsf@xmission.com>

Quoting Eric W. Biederman (ebiederm@xmission.com):
> Eric Paris <eparis@parisplace.org> writes:
> 
> > Why trust uids or rwx bits.  Might as well do away with those as well,
> > right?
> 
> Lying to your own userspace processes (which you can do with LD_PRELOAD)
> is rather different than lying to the selinux or the smack modules.
> 
> What I am saying with my patch is that fuse is remarkably non-nuanced
> in how it interacts with extended attributes, and that it appears
> very clear that there are bugs in the area of unprivileged mounts that
> need to be addressed.
> 
> I am happy to hear about better solutions.  Telling me it's not a bug
> and sticking your head in the sand is quite amusing.

I'm not terribly familiar with the ways fuse modules can be loaded.
Would it be possible to, at load time, based on the (selinux) credentials
of the user loading the module, either allow the loader to specify that
security.* and trusted.* xattrs may be used, or, if user is unprivileged,
ignore the xattrs and use a default based on the user's credentials?

-serge

  reply	other threads:[~2012-10-08 13:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-05 22:50 [PATCH] fuse: Only allow read/writing user xattrs Eric W. Biederman
2012-10-06 14:23 ` Eric Paris
2012-10-06 15:34   ` Eric W. Biederman
2012-10-06 15:57     ` Eric Paris
2012-10-06 23:42       ` Eric W. Biederman
2012-10-08 13:47         ` Serge Hallyn [this message]
2012-10-08 14:02         ` Eric Paris

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=20121008134751.GB5351@sergelap \
    --to=serge.hallyn@canonical.com \
    --cc=ebiederm@xmission.com \
    --cc=eparis@parisplace.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).