Date: Sun, 28 Apr 2002 15:59:44 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Richard Arends <richard@unixguru.nl> Cc: Kris Kennaway <kris@obsecurity.org>, current@FreeBSD.ORG Subject: Re: truss Message-ID: <Pine.NEB.3.96L.1020428155321.64976M-100000@fledge.watson.org> In-Reply-To: <20020428210839.J52867-100000@mail.unixguru.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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 from. 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 robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020428155321.64976M-100000>