On Sun, 28 Apr 2002, Richard Arends wrote:
> > I think truss is one of the last stragglers that relies on it --
> > the other is 'ps -e', which gropes through the memory of each process to
> > dig out the environmental variables. This requires that ps both have
> > substantial privilege, and that procfs be present.
> Can't we take the privileges away, so that an user only can see his own
> procs and only root can see all??
It's a little more complicated than that. The problem was that procfs
provided extremely broad access to the system, but without much
granularity. Mostly this meant that if you had root privilege, you could
do whatever you wanted, and otherwise, you got a reasonable view of the
system (modulo the countless security holes in procfs). So the problem
was that ps ran with a lot of privilege -- generally root or 'gid kmem'
which amounts to much the same thing. This meant that gating of process
information happened in the ps command, or at least, with the help of the
ps command deciding not to get around the information gating. In FreeBSD
4.0, this responsibility happens both in userland and the kernel -- the
kernel makes some effort to limit access via procfs, but largely allows
privileged processes access to most things. So the ps command implemented
the limit on what processes you could extract environmental information
In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which provides much more information gating, and
flexibe policy controls. This exists in part in 4.x, but not completely.
In 5.0, ps requires no special privilege, and access control is done
entirely in the kernel. However, giving up the ability to grope through
the memory of other processes by giving up procfs does limit that one
capability -- listing environmental variables. For ps to display this
information, either it has to extract it using a kernel facility (such as
procfs), or the kernel has to extract it and provide it to ps. So far,
we've had to rule out the first due to the security issues, but the second
hasn't been implemented. It's not clear there's enough interest in it
that someone has felt motivated to do so. Patches would be accepted here,
but I think there's some concensus it's not really a necessary feature,
and it also raises a lot of security issues of its own (you'd be surprised
what ends up in environmental variables, and how hard it is to keep policy
in sync between userland and kernel).
BTW, 5.0 will also allow (once we commit the MAC framework from the
TrustedBSD Project) kernel modules to tweak process visibility protections
in the kernel at runtime. For example, you can kldload a
mac_seeotheruids.ko policy module, which can limit what processes can view
of other processes based on a number of factors, including uids, and
information it tags onto the processes. It can also limit access to
socket information listed in netstat, etc.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message