lkml.org 
[lkml]   [2003]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectposix capabilities inheritance
I wrote a simple setuid-root wrapper which sets some capabilities, 
gives up all other privs, and and then execs a shell. I was hoping
to use this wrapper as a login shell so that I could have a user
log in interactively with a small subset of elevated privileges.

Unfortunately after looking over the capabilities code in the 2.4
kernel, it would appear that this is not currently possible, and
my wrapper cannot work without filesystem support for capabilities.
And even then, I'd have to set each file's inheritable flag for the
capabilities I want on every executable that I am likely to run,
including the shell. Am I mising something, or is this an accurate
description?

I think I understand the rationale behind this behavior; the draft
posix 1003.1e specification states:

The purpose of assigning capability states to files is
to provide the exec() function with information regarding
the capabilities that any process image created with the
program in the file is capable of dealing with and have
been granted by some authority to use.

So, the lack of an inheritable flag on a file can serve to prevent
that file from executing with the corresponding capability enabled.

Fine, but what about my semi-superuser shell situation? How can
I force the retention of a capability set across exec() for all
executables? It would seem that neither the spec nor the current
implementation in the 2.4 kernel allow for this, but it strikes
me as a pretty reasonable and useful thing to do in some cases.

As an interim workaround, how about assuming all capabilities are
inheritable in fs/exec.c:prepare_binprm, i.e. instead of
cap_clear(bprm->cap_inheritable), call cap_set_full() ??? I don't
think this would break anything, and it would make capabilities a
lot more useful until we get fs support merged in.

--
Michael Glasgow < glasgow at beer dot net >
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.259 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site