Re: [PATCH v2 0/3] fuse: Add support for mounts from pid/user namespaces

[Eric W. Biederman]

Seth Forshee <seth.forshee@xxxxxxxxxxxxx> writes:

> On Tue, Sep 23, 2014 at 03:29:57PM -0700, Eric W. Biederman wrote:
>> 
>> So thinking about this and staring at fuse a little more I don't like
>> the approach of mapping bad uids into INVALID_UID in the case of fuse.
>> 
>> What scares me is that we are looking at a very uncommon case that no
>> one will test much.  And depending for security on a very subtle
>> interpretation of semantics that only matter when someone is attacking
>> us seems scary to me.
>> 
>> For fuse at least I would assume that any time a file shows up with a
>> uid that doesn't map, and we map it to INVALID_UID I would assume it is
>> the work of a hostile user.  It could be a misconfiguration but it is a
>> broken action on the part of the filesystem in either case.
>> 
>> Therefore given that a bad uid can only occur as a result of accidental
>> or hostile action can we please call make_bad_inode in those cases?  And
>> thus always return -EIO.
>> 
>> That way no one needs to consider what happens if we cache bad data or
>> we try to use bad data, and it is an easy position to retreat from
>> if it happens that we need to do something different.
>
> One thing I don't understand is why you're qualifying these statements
> to be limited to fuse. Normal filesystems will have to deal with the
> same problem if/when they are made mountable from user namespaces; is
> this concern not valid there? Or would you advocate the same behavior
> for normal filesystems as well? Otherwise it seems like we're just
> putting off dealing with it for a while.

I am qualifying them with fuse so that my thinking is concrete.  I
believe my thinking generalizes to all filesystems, but I there may be
cases I have not considered that are different.

> I'd prefer for the mounts to be as useful as possible when the fs
> contains ids that don't map into the namespace, but it's also difficult
> to argue against taking the more restricted approach at first and
> loosening up if needed. So I guess I'm okay with returning -EIO to start
> out.

What bugs me the most about making the mounts as useful as possible is
that it makes an assumption about why the uids are corrupt.

I look at the situtation and I make a different assumption that the most
likely reasons for the uids to be corrupt is someone being malicious.
Being as useful as possible when someone is being malicious feels like
a recipe for the malicious user to exploit your generousity.

So in summary I see:
- Low utility in being able to manipulate files with bad uids.
- Bad uids are mostly likely malicious action.
- make_bad_inode is trivial to analyze.
- No impediments to change if I am wrong.

So unless there is a compelling case, right now I would recommend
returning -EIO initially.   That allows us to concentrate on the easier
parts of this and it leaves the changes only in fuse.

I have no problems revisiting this later and in fact I am half persuaded
we should, but simultaneously dealing working on both fuse and the
generic problem of how to handle files with bad uids and gids seems
too much to analyze and digest all at once.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/