Date: Sun, 27 Aug 2000 12:39:08 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-security@FreeBSD.org Cc: phk@FreeBSD.org, green@FreeBSD.org Subject: Review request: replacing p_trespass(), modifications to vaccess() Message-ID: <Pine.NEB.3.96L.1000827123021.72392A-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
I've put up a patch that makes fairly extensive changes to the structure (but hopefully not the semantics) of inter-process authorization checks: http://www.freebsd.org/~rwatson/p_stuff.diff In theory, it does the following: 1) Replace many instances of {p_trespass, PRISON_CHECK} with one of {p_cansee, p_cansched, p_candebug, and p_cankill}, which are in kern_prot.c. This centralizes the inter-process access control in a more general way, and allows differentiation of the different types of interaction. For example, Brian Feldman's patch to modify setting of realtime priority changed the semantics for scheduling modifications, because p_trespass() is more liberal than the old authorization check. These changes should fix that. 2) Integrate the new kern.ps_showallproc change into p_cansee(), which has the effect of adding support to procfs also, whereas the existing sysctl affects only sysctl() access to the process data. 3) Modify vaccess() so that it is restructured for more careful/ordered use of privilege, and so that capability support can be added more easily. This should be semantically the same from a results perspective, but it is more careful to do a discretionary access check before falling back in privilege, et al. As such, the KSU accounting bit will now be set correctly in vaccess() for processes running as uid 0, if they use privilege to access a file rather than discretionary rights. My hope is that the only "changed" behavior is: 1) Fix the p_trespass() interaction with regards to scheduling changes 2) Make kern.ps_showallproc affect /proc It should be noted that right now, some information is still leaked via /proc, but only the existence of the pid, rather than any practical process information. This could be gathered using a walking fork()'ing process anyway looking for pid holes, anyway, but I'm looking into a solution (it probably has to do with the name cache, as I mentioned on -fs this morning, so may not be easily fixable.) 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.1000827123021.72392A-100000>