Re: [RFC][PATCH 1/1] support optional non-VFS capability inheritance without disabling file caps

[Andrew G. Morgan]

Naive process inheritance of privilege is one of the things this whole
infrastructure is trying to discourage...

Overlays aside, is there some limit on the sophistication of your
filesystem setup? Presumably, one could create a small filesystem in a
file and, using the loopback device, mount it. Such a filesystem could
have xattrs ACLs and filecaps and give you all the specificity you
need for this purpose. /chroot/mnt/sbin/ etc.

Cheers

Andrew

On Fri, Aug 14, 2009 at 8:40 AM, Will Drewry<redpig@xxxxxxxxxxxxx> wrote:
> On Fri, Aug 14, 2009 at 8:32 AM, Serge E. Hallyn<serue@xxxxxxxxxx> wrote:
>> Quoting Will Drewry (redpig@xxxxxxxxxxxxx):
> [snip]
>>> This allows for a purely runtime capabilities-based environment without
>>> requiring every file to be annotated with an extended attribute.  This
>>
>> Well, we have that ability now - only files which need to be executed
>> *with* *privilege* need an xattr.
>
> Of course - I was thinking of it in terms of temporally restricted
> (runtime) instead of reapplied by the fs on each go which I realize is
> directly opposed to the idea of the executable itself having the
> privileges.
>
>>> also means that SECURE_NOROOT process trees using capabilities become
>>> more accessible, especially for filesystems without extended attribute
>>> support - or in mixed FS environments.
>>
> [snip]
>> Heck, maybe we can use the fscache or a stackable fs to provide a view
>> of a non-xattr fs with xattrs layered on top.  David Howells, does
>> that sound doable or would that be an abuse?
>
> I haven't looked at much fscache (but I look forward to hearing back), but
> a stackable fs might make sense.  A simple way to layer xattrs on top
> of any filesystem would be a welcome transititory step for a xattr-less
> filesystem, but it could be a bit clumsy.
>
>> Will, let me be sure we're on the same page - you don't want this feature
>> bc you don't want to go through the trouble of adding file capabilities
>> to the executables which need and deserve it, but because in your
>> environment you have an FS which doesn't support file caps and so
>> there is no way for you to have a SECURE_NOROOT|SECURE_NOSUID_FIXUP
>> environment because you need to run a privileged program off of the
>> non-xattr fs?
>
> Yes and more. On one side, I am looking to run privileged programs from
> a non-xattr fs in a SECURE_NOROOT|SECURE_NOSUID_FIXUP environment, but I
> am also interested in granting capabilities contextually where the
> context is the specific process ancestry.  In many cases, a binary
> with a capability xattr doesn't need extra privileges all the time
> but only when called via an expected path.
>
> That approach would make it possible to use a smaller, well-audited
> binary that can grant capabilities from their bounding set _only_ when
> it makes the decision to do so (suidwrapper-style, I guess).  If the
> system supports xattrs, then it would mean this binary gets
> xattr-flagged and not the actual code.  (This can be synthesized by
> having a daemon use setfcaps to toggle the setting on a file during
> execution which, at worst, would yield a race condition, but probably
> nothing too terrifying...)
>
>>> Nb, I may be missing something obvious - any insights will be appreciated,
>>>     and there is a good bit of flexibility in what can be done here.
>>
>> I don't know whether or not you're missing something, but of course
>> what we give up with your patch is the feature that all privilege to
>> a process is in the end granted by the executable.  I'll admit that
>> of the like patches I've seen, yours makes the most sense.  My main
>> concern would be that it would make things more confusing, so if we
>> can fix the problem another way, without adding yet another set of
>> semantics, that would be preferable.  However if that is not feasible,
>> I might be inclined to ack this.
>
> I can definitely see the room for confusion - at any point, you'd need
> to take a getcaps(pstree) to see your current capability state (or
> have a process-cred-enumerating module).  Right now, you only need to
> do that if you'd like to know the current inherited capability state.
> That's part of the reason why I thought it'd be important to treat this
> as a separate mode of operation for a process tree via securebits.
> Hopefully the guard bit will keep pure, xattr-based use unmuddied by
> this hybrid process-driven capability model.
>
> A stackable filesystem seems like it could provide a nice stepping stone
> for xattr-less filesystems, but implementing one with
> xattrs-based-on-calling-process would be more convoluted imho without
> patching more code to be capability aware (or making a crazy
> process-tree walking stackable fs with a proc/ioctl/whatever interface
> for setting the equivalent securebit for a process tree :).
>
> If all current daemons were capability-aware, then a +i tree would be
> possible where a process transitioning to SECURE_NOROOT|NOFIXUP could
> leave all later expected capabilities as +i, then any 'potentially' a +i
> and then when the +i xattr exists on a file (via the stackable fs).
>
> I would understand if you don't think that is compelling enough to merit
> an additional mode of operation, but I hope that it expands the utility
> of the capability system without too much fuss.
> [unless a better solution really is available]
>
> Thanks!
> will
>
--
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/