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

[Serge E. Hallyn]

Quoting Will Drewry (redpig@xxxxxxxxxxxxx):
> Capabilities marked as inheritable (+i) are inaccessible when inherited
> by a child process (after exec()) with CONFIG_SECURITY_FILE_CAPABILITIES
> enabled unless the VFS entry of the child also provides the capability (or
> cap_setpcap) in the permitted/effective sets.
> 
> This change adds a securebit, SECURE_INHERIT_CAPS, which enableÑ
> inherited capabilities to be propagated to the permitted set of the
> child process.  If it doesn't conflict with VFS_CAP_FLAGS_EFFECTIVE, it
> will also mark the capabilities effective.  This bit and change only
> take effect when SECURE_NOROOT is set.
> 
> The securebit guard is used because this change violates the following
> constraint:
>         pP' = (X & fP) | (pI & fI)
> With bit-6 enabled, the constraint becomes:
>         pP' = (X & fP) | (pI)
> and pE' varying based on VFS bits and if there are any file-based capabilities.
> 
> 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.

> also means that SECURE_NOROOT process trees using capabilities become
> more accessible, especially for filesystems without extended attribute
> support - or in mixed FS environments.

<sigh>  Well, this *is* a problem.  I wonder whether perhaps we should
instead be trying to either think of a way to specify file capabilties
on non-xattr file systems, or working harder to provide xattrs
everywhere.

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?

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?

> For example, a daemon like dhcpcd may be launched with cap_net_raw by a
> more privileged daemon.  Once dhcpcd drops the cap_net_raw privilege, it
> will not be able to regain it.  Even if a local user runs dhcpcd
> manually, the capability will not be granted because the capability was
> not derived from the filesystem.  However, the calling capability
> manager could either gain its permissions from init or by having a
> file-based capability set.
> 
> 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.

thanks,
-serge
--
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/