[cap-talk] Don't put capabilities in argv?

[Kevin Reid]

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.


Further thoughts:

* 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 [1] and update the CLI.txt docs [2] 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
done


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  
> LSM
> to prohibit non root processes from accessing this information.

Will this automatically work against 'ps'?

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>