Date: Wed, 4 Oct 2000 14:06:11 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: cjclark@alum.mit.edu Cc: freebsd-security@freebsd.org Subject: Re: Fwd: eth-security : ANNOUNCE : Resources no for ALL Message-ID: <Pine.NEB.3.96L.1001004123750.5070F-100000@fledge.watson.org> In-Reply-To: <20001004084729.C25121@149.211.6.64.reflexcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Oct 2000, Crist J . Clark wrote: > Restricted kernel process table and proc filesystem > *---------------------------------------------------* > > This patch gives limited access for non-root to process table ,only root > see all process and have access to their entries in proc filesystem. > Permission to directories in proc filesystem is changed > to 550 (dr-xr-x---) .Non-root users can only see own proceses. A feature very like this is present in 5.0-CURRENT, only /proc actually limits what processes can see there. Also, linprocfs is protected. You can set that feature using "sysctl -w kern.ps_showallprocs=0" with privilege. This feature was originally introduced by Paul Saab, I believe, but its incarnation in 4.x-STABLE isn't very complete, and doesn't protect /proc and linprocfs. My structural changes in inter-process authorization in the -CURRENT branch included the procfs fixes. Note that although this does protect /proc from listing processes that are owned by other users, it is still possible to walk the PID space using fork()/getpid() to identify in-use PIDs. I have not looked at backporting the inter-process authorization changes to -STABLE, as they're part of a larger structural improvement slated for inclusion in 5.0-CURRENT. However, they probably can be usefully isolated and MFC'd if the feature is desirable. > Restricted who/w/last > *---------------------------------------------------* > > Restricted who/w/last gives limited access to utmp/wtmp entries. > Users can see only own login to system (no group like w_all,w_grp) , > but if user is added to group w_grp can see own and group login . > Group w_all is for trusted users that have full read access to utmp/wtmp . Unless you make who/w/last privileged in some way and restrict access to utmp/wtmp based on that privilege (setgid or the like), these will only be advisory protections. I.e., changes only to the binaries offers no real protection. Requiring privilege for access to utmp may break many things. That's not to say this can't be done, just that it's a bit more complicated than adding permission checks to the tools themselves. It might be interesting, at some point, to move to keeping utmp-like information in kernel and accessing it via a MIB, rather than using a file: processes would be allowed to change certain entries based on access to the pty in question, but existing privileged calls would be required to set login names, etc. Wtmp has to remain a file for the obvious reasons. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" 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.1001004123750.5070F-100000>