[cap-talk] Don't put capabilities in argv?
kpreid at mac.com
Sat Jul 12 19:14:24 CDT 2008
On Jul 12, 2008, at 17:43, Kevin Reid wrote:
> AFAIK, typical unix systems reveal command-line arguments of all
> processes to all users.
> This implies that (except on a machine where you don't use unix users
> for isolation) password capabilities should not be passed as
> arguments; also that using command-line tools with a password-cap file
> system such as MinorFs or Tahoe is unsafe.
* The simplest safe-by-default mechanism I can think of is to read the
capability from a file whose name is passed on the command line.
* More elaborate: read the capability from a URL (file: or data:
only) instead of a plain pathname; then when it is safe, capabilities
may be passed without the cost of file creation, permission
management, and lifetime, as data: URLs.
On Jul 12, 2008, at 18:01, zooko wrote:
> I guess this means that the "aliases" in the tahoe CLI, which we were
> already supporting for convenience reasons now needs to become the
> only way to refer to capabilities in your command-line.
> It also means that we need to add this security issue to the known
> issues file  and update the CLI.txt docs  to not encourage
> people to use caps on the command-line.
I think direct specification of capabilities should continue to exist,
with appropriate warnings.
* There are a lot of machines out there for which this isn't an
issue; for example, single-actual-users who don't practice any
privilege separation (extremely common), or virtual machines which (I
would guess) run only root and a single other account running the
application for which it exists.
* As Rob Meijer points out, it is possible to hide argv on some
systems, and even common security ideas suggest the usefulness of argv.
* It is not uncommon for username-and-password systems -- and
remember that passwords often give much more authority than a typical
capability -- to support a command-line option for specifying the
password. That this is not widely considered a Really Bad Idea To Even
Exist suggests that people are finding use for these options and not
suffering for it.
On Jul 12, 2008, at 18:43, David Wagner wrote:
> Overwrite your own argv to hide the command-line arguments. You'll
> want to overwrite environ, too. (Of course, this leaves open a
> hopefully short time window before you manage to overwrite argv,
> during which command-line arguments are still visible to someone who
> looks at just the right time.)
while true; do
ps axww | grep cap: >> gathered
On Jul 12, 2008, at 19:16, Rob Meijer wrote:
> Depending on the field of usage, AppArmor might be used to keep
> applications from accesing /proc/$PID/cmdline, as could SELinux (I'm
> not a
> big SELinux fan). It would also be quite feasible to create a simple
> to prohibit non root processes from accessing this information.
Will this automatically work against 'ps'?
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the cap-talk