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

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

[Will Drewry]

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

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.

Signed-off-by: Will Drewry <redpig@dataspill.org>
---
include/linux/securebits.h |   12 +++++++++++-
security/commoncap.c       |    7 +++++++
2 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/include/linux/securebits.h b/include/linux/securebits.h
index d2c5ed8..ed50b80 100644
--- a/include/linux/securebits.h
+++ b/include/linux/securebits.h
@@ -27,6 +27,15 @@
 #define SECURE_KEEP_CAPS		4
 #define SECURE_KEEP_CAPS_LOCKED		5  /* make bit-4 immutable */

+/* When set, any capabilities inherited from a parent process will
+   start in the permitted, and possibly effective, capability set
+   if SECURE_NOROOT is set.
+     pP' = (X & fP) | (pI & fI)
+   becomes
+     pP' = (X & fP) | (pI) */
+#define SECURE_INHERIT_CAPS		6
+#define SECURE_INHERIT_CAPS_LOCKED	7  /* make bit-6 immutable */
+
 /* Each securesetting is implemented using two bits. One bit specifies
    whether the setting is on or off. The other bit specify whether the
    setting is locked or not. A setting which is locked cannot be
@@ -36,7 +45,8 @@

 #define SECURE_ALL_BITS		(issecure_mask(SECURE_NOROOT) | \
 				 issecure_mask(SECURE_NO_SETUID_FIXUP) | \
-				 issecure_mask(SECURE_KEEP_CAPS))
+				 issecure_mask(SECURE_KEEP_CAPS) | \
+				 issecure_mask(SECURE_INHERIT_CAPS))
 #define SECURE_ALL_LOCKS	(SECURE_ALL_BITS << 1)

 #endif /* !_LINUX_SECUREBITS_H */
diff --git a/security/commoncap.c b/security/commoncap.c
index 48b7e02..9b4590d 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -508,6 +508,13 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
 		}
 		if (new->euid == 0)
 			effective = true;
+	} else if (issecure(SECURE_INHERIT_CAPS)) {
+		/* Only enable permitted-to-effective inheritance if it doesn't
+		 * override VFS_CAP_FLAGS_EFFECTIVE behavior. */
+		if (!effective && cap_isclear(new->cap_permitted))
+			effective = true;
+		new->cap_permitted = cap_combine(new->cap_permitted,
+						 new->cap_inheritable);
 	}
 skip:

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

[Serge E. Hallyn]

Quoting Will Drewry (redpig@dataspill.org):
> 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

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

[Will Drewry]

On Fri, Aug 14, 2009 at 8:32 AM, Serge E. Hallyn<serue@us.ibm.com> wrote:
> Quoting Will Drewry (redpig@dataspill.org):
[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

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@dataspill.org> wrote:
> On Fri, Aug 14, 2009 at 8:32 AM, Serge E. Hallyn<serue@us.ibm.com> wrote:
>> Quoting Will Drewry (redpig@dataspill.org):
> [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
>

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

[Will Drewry]

On Sat, Aug 15, 2009 at 12:22 PM, Andrew G. Morgan<morgan@kernel.org> wrote:
> Naive process inheritance of privilege is one of the things this whole
> infrastructure is trying to discourage...

Hrm I know that was more of the intent of POSIX file capabilities
(AFAICT), but I was under the impression that the full picture of
capabilities in linux were more about moving away from a default-on,
binary superuser privilege policy.  But you'd know what your intentions
were better than me :)

I was hoping that a process inheritance approach wouldn't be considered
the same as root inheritance is now.  It operates with the same
granularity as the file-based approach except that it allows these
lesser privilege sets to be limited in time for a binary. E.g.,
it'd be nice if pulseaudio could be started with privileges only at,
let's say, login-time for a user and not when a remote attacker needs to
bypass mmap_min_addr.

> 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.

That's a perfectly nice workaround (especially since it'd be easy enough
to pair with some symlinks), but I am interested in both issues --
xattr-less filesystems and the inflexibility of filesystem-based
security policy.

If the patch (and my intentions) are irreconcilably at odds with the
capability system (and securebits) goals, then I can definitely evaluate
other avenues as well as revisit the underpinnings of my plans.  I was
just hoping that this would fit in under the current umbrella (e.g., like
the other root-to-capability-mode transition fixups).

If it's a hopeless case, please let me know!  However, I'm happy to
make any number of changes if something like this is feasible.

thanks!
will

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

[Andrew G. Morgan]

Will,

I've read this over a few times, but the in-lining is confusing me.
The idea of tying privilege only to 'anointed' binaries is the "POSIX"
capabilities model.

If you are willing to concede that one can always arrange xattrs to be
convenient with various filesystem mounting techniques, are you saying
you would like all executables to be able to wield privilege if their
parent wants to give it to them?

Thanks

Andrew

On Sat, Aug 15, 2009 at 9:24 PM, Will Drewry<redpig@dataspill.org> wrote:
> On Sat, Aug 15, 2009 at 12:22 PM, Andrew G. Morgan<morgan@kernel.org> wrote:
>> Naive process inheritance of privilege is one of the things this whole
>> infrastructure is trying to discourage...
>
> Hrm I know that was more of the intent of POSIX file capabilities
> (AFAICT), but I was under the impression that the full picture of
> capabilities in linux were more about moving away from a default-on,
> binary superuser privilege policy.  But you'd know what your intentions
> were better than me :)
>
> I was hoping that a process inheritance approach wouldn't be considered
> the same as root inheritance is now.  It operates with the same
> granularity as the file-based approach except that it allows these
> lesser privilege sets to be limited in time for a binary. E.g.,
> it'd be nice if pulseaudio could be started with privileges only at,
> let's say, login-time for a user and not when a remote attacker needs to
> bypass mmap_min_addr.
>
>> 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.
>
> That's a perfectly nice workaround (especially since it'd be easy enough
> to pair with some symlinks), but I am interested in both issues --
> xattr-less filesystems and the inflexibility of filesystem-based
> security policy.
>
> If the patch (and my intentions) are irreconcilably at odds with the
> capability system (and securebits) goals, then I can definitely evaluate
> other avenues as well as revisit the underpinnings of my plans.  I was
> just hoping that this would fit in under the current umbrella (e.g., like
> the other root-to-capability-mode transition fixups).
>
> If it's a hopeless case, please let me know!  However, I'm happy to
> make any number of changes if something like this is feasible.
>
> thanks!
> will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Will Drewry]

Hi Andrew,

Cool, so yes, I would like for a parent process to be able to
grant a subset of its privileges to its children.

I am interested in this approach for two reasons:
1. provides xattr-less filesystem SECURE_NOROOT 'support'
2. provides ephemeral capabilities

For #1, I concede that there are any number of workarounds to achieve
xattr support on a given system.  As with any workaround, they come with
some overhead, be it in additional kernel support or in system
management overhead.  However, those can be dealt with at a non-kernel
level for the most part.

For #2, it is currently the case that if a given user can run a binary
with capabilities, they can always run it with those capabilities, just
like a SUID binary.  I would like support to empower a given process
tree with a capability that is not granted unless that process tree has
been traversed.

IMHO, a good example is /usr/bin/pulseaudio.  On most distributions, it
is a SUID binary, but it could probably get by with cap_sys_rawio+ep.
However, even with 'setcap cap_sys_rawio+ep', it would still provide the
attack platform used in several recent kernel NULL pointer dereferencing
exploits.  Any user that can normally execute pulseaudio can do so at
anytime.  However, it would be preferable if a user's pulseaudio sound
server was run once with privilege (on X11 login, perhaps) instead of
anytime during a given session.

It is almost possible to achieve #2 on existing systems, assuming xattr
support can always be achieved.
Step 1, setcap cap_sys_rawio+i /usr/bin/pulseaudio
Step 2, pam_cap at X11 login to add cap_sys_rawio+i for a user session
(alternately, use capsh).
Step 3, run pulseaudio (pP' = (...) | (fI & pI) => cap_sys_rawio+ip)

It would mean that that specific user-session could launch pulseaudio
with cap_sys_rawio+ip but not necessarily any active user with +x
privileges on the pulseaudio binary. In addition, at any point in the
session, cap_sys_rawio could be dropped permanently which would block
future reuse/abuse (without relogin).

The problem with this approach is that many existing applications are
capability-ignorant.  Since the capabilities granted above
would be in the inherited and permitted sets only, these legacy
applications would still lack the privileges they need -- even if only
because they are too dumb to fix it.  To get the same effect, each of
these daemons/packages/etc will need to be patched to attempt to setpcap
any capabilities they might need to move them into the effective set.

My proposal would alleviate the need to independently patch existing code
and would avoid filesystem-related workarounds.  I'm looking at the
change as a compatibility feature. root privileges could be parceled but
still inherited - but only when the new securebit is set.

I hope that I'm making a bit more sense this go around.  Sorry for any
confusion.

thanks!
will

On Sun, Aug 16, 2009 at 11:50 PM, Andrew G. Morgan<morgan@kernel.org> wrote:
> Will,
>
> I've read this over a few times, but the in-lining is confusing me.
> The idea of tying privilege only to 'anointed' binaries is the "POSIX"
> capabilities model.
>
> If you are willing to concede that one can always arrange xattrs to be
> convenient with various filesystem mounting techniques, are you saying
> you would like all executables to be able to wield privilege if their
> parent wants to give it to them?
>
> Thanks
>
> Andrew

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

[Andrew G. Morgan]

On Mon, Aug 17, 2009 at 7:38 AM, Will Drewry<redpig@dataspill.org> wrote:
> Hi Andrew,
>
> Cool, so yes, I would like for a parent process to be able to
> grant a subset of its privileges to its children.
>
> I am interested in this approach for two reasons:
> 1. provides xattr-less filesystem SECURE_NOROOT 'support'
> 2. provides ephemeral capabilities
>
> For #1, I concede that there are any number of workarounds to achieve
> xattr support on a given system.  As with any workaround, they come with
> some overhead, be it in additional kernel support or in system
> management overhead.  However, those can be dealt with at a non-kernel
> level for the most part.
>
> For #2, it is currently the case that if a given user can run a binary
> with capabilities, they can always run it with those capabilities, just
> like a SUID binary.  I would like support to empower a given process
> tree with a capability that is not granted unless that process tree has
> been traversed.
>
> IMHO, a good example is /usr/bin/pulseaudio.  On most distributions, it
> is a SUID binary, but it could probably get by with cap_sys_rawio+ep.
> However, even with 'setcap cap_sys_rawio+ep', it would still provide the
> attack platform used in several recent kernel NULL pointer dereferencing
> exploits.  Any user that can normally execute pulseaudio can do so at
> anytime.  However, it would be preferable if a user's pulseaudio sound
> server was run once with privilege (on X11 login, perhaps) instead of
> anytime during a given session.
>
> It is almost possible to achieve #2 on existing systems, assuming xattr
> support can always be achieved.
> Step 1, setcap cap_sys_rawio+i /usr/bin/pulseaudio
> Step 2, pam_cap at X11 login to add cap_sys_rawio+i for a user session
> (alternately, use capsh).
> Step 3, run pulseaudio (pP' = (...) | (fI & pI) => cap_sys_rawio+ip)

What about filecaps of cap_sys_rawio+eip on pulseaudio. With the
bounding set suppressing cap_sys_rawio?

In this case, only a process with (pI & cap_sys_rawio) can exec()ute
pulseaudio, let alone use the capability. That is, the filecap +pe
implies that the capability is required for the app to run, but the
bounding set suppresses the bit from the file's xattr...! The only way
that the exec()d program can get this required bit is from the (pI &
fI), and so only if a process has (pI & cap_sys_rawio) will it be able
to invoke the program...

Cheers

Andrew

>
> It would mean that that specific user-session could launch pulseaudio
> with cap_sys_rawio+ip but not necessarily any active user with +x
> privileges on the pulseaudio binary. In addition, at any point in the
> session, cap_sys_rawio could be dropped permanently which would block
> future reuse/abuse (without relogin).
>
> The problem with this approach is that many existing applications are
> capability-ignorant.  Since the capabilities granted above
> would be in the inherited and permitted sets only, these legacy
> applications would still lack the privileges they need -- even if only
> because they are too dumb to fix it.  To get the same effect, each of
> these daemons/packages/etc will need to be patched to attempt to setpcap
> any capabilities they might need to move them into the effective set.
>
> My proposal would alleviate the need to independently patch existing code
> and would avoid filesystem-related workarounds.  I'm looking at the
> change as a compatibility feature. root privileges could be parceled but
> still inherited - but only when the new securebit is set.
>
> I hope that I'm making a bit more sense this go around.  Sorry for any
> confusion.
>
> thanks!
> will
>
> On Sun, Aug 16, 2009 at 11:50 PM, Andrew G. Morgan<morgan@kernel.org> wrote:
>> Will,
>>
>> I've read this over a few times, but the in-lining is confusing me.
>> The idea of tying privilege only to 'anointed' binaries is the "POSIX"
>> capabilities model.
>>
>> If you are willing to concede that one can always arrange xattrs to be
>> convenient with various filesystem mounting techniques, are you saying
>> you would like all executables to be able to wield privilege if their
>> parent wants to give it to them?
>>
>> Thanks
>>
>> Andrew
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Will Drewry]

On Mon, Aug 17, 2009 at 10:26 AM, Andrew G. Morgan<morgan@kernel.org> wrote:
> On Mon, Aug 17, 2009 at 7:38 AM, Will Drewry<redpig@dataspill.org> wrote:
[snip]
>> It is almost possible to achieve #2 on existing systems, assuming xattr
>> support can always be achieved.
>> Step 1, setcap cap_sys_rawio+i /usr/bin/pulseaudio
>> Step 2, pam_cap at X11 login to add cap_sys_rawio+i for a user session
>> (alternately, use capsh).
>> Step 3, run pulseaudio (pP' = (...) | (fI & pI) => cap_sys_rawio+ip)
>
> What about filecaps of cap_sys_rawio+eip on pulseaudio. With the
> bounding set suppressing cap_sys_rawio?
>
> In this case, only a process with (pI & cap_sys_rawio) can exec()ute
> pulseaudio, let alone use the capability. That is, the filecap +pe
> implies that the capability is required for the app to run, but the
> bounding set suppresses the bit from the file's xattr...! The only way
> that the exec()d program can get this required bit is from the (pI &
> fI), and so only if a process has (pI & cap_sys_rawio) will it be able
> to invoke the program...

Aha! I was missing something.  I was thinking that the bounding set was
still governing system-wide despite the fact it was right in front of me
that it wasn't (kernel source, capsh).

This works perfectly and achieves the exact same goal of step-down root
permissions with run-time inheritance-based management.

I guess we can bin the patch since I doubt xattr-less filesystems are
worth the change. (I might whip up a stackable one just to avoid dealing
with symlinks and loopbacks :)

Thanks for working through this with me.  Sorry that it took a few
rounds.

cheers!
will

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

[Andrew G. Morgan]

On Mon, Aug 17, 2009 at 9:48 AM, Will Drewry<redpig@dataspill.org> wrote:
> Thanks for working through this with me.  Sorry that it took a few
> rounds.

Excellent! :-)

Cheers

Andrew

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

[David Howells]

Serge E. Hallyn <serue@us.ibm.com> wrote:

> 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?

You could use fscache, but you would have to deal with the cache not being
available or suddenly going away.  Note that fscache does not stack on top of
another fs in Linux in the way it does in Solaris - the non-xattr fs would
have to actively talk to fscache.  But it's certainly possible.

David