[cap-talk] Don't put capabilities in argv?
capibara at xs4all.nl
Sat Jul 12 18:16:47 CDT 2008
On Sat, July 12, 2008 23: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.
> Has this been noticed before? Are there ways to eliminate the problem?
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.
Not many programs will break by restricting access to /proc in such a way
that /proc/self is accesible but /proc/$PID is not. Making these programs
root:wheel 0770 might be an option in some circumstances. A more elaborate
AppArmor or SELinux profile for accessing /proc might be needed for the
more general case.
It would be very interesting to get a list of programs that break when
using the simple approach that /proc/$PID shoud be inaccesible and only
/proc/self should be accesible.
More information about the cap-talk