Date: Thu, 12 Apr 2001 00:50:59 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-audit@FreeBSD.org Cc: tmm@FreeBSD.org Subject: relationship between credential-managing daemons and normal processes Message-ID: <Pine.NEB.3.96L.1010412001239.97720C-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Earlier today, I committed the beginnings of an inter-process authorization regression testing suite. My goal was to make sure that, as we replace the current authorization code, no vulnerabilities be introduced as a result of accidental changes, as well as to take a look at the correctness of the current implementation. The regression testing suite actually explores a slightly larger state space than the kernel provides to user processes, by virtue of its testing of a number of cases where the P_SUGID bit is turned off but isn't in normal operation. The following excerpt comes from executing the suite on a FreeBSD 5.0-CURRENT box this evening: test capabilities: [SETSUGID_SUPPORTED_BUT_NO_LIBC_STUB] [CHECK_CRED_SET] [20. unpriv1 on daemon1].signal: expected EPERM, got 0 (e:1000 r:1000 s:1000 P_SUGID:0)(e:1000 r:0 s:0 P_SUGID:0) [20. unpriv1 on daemon1].sched: expected EPERM, got 0 (e:1000 r:1000 s:1000 P_SUGID:0)(e:1000 r:0 s:0 P_SUGID:0) [21. unpriv1 on daemon1].signal: expected EPERM, got 0 (e:1000 r:1000 s:1000 P_SUGID:0)(e:1000 r:0 s:0 P_SUGID:1) [21. unpriv1 on daemon1].sched: expected EPERM, got 0 (e:1000 r:1000 s:1000 P_SUGID:0)(e:1000 r:0 s:0 P_SUGID:1) [22. unpriv1 on daemon1].signal: expected EPERM, got 0 (e:1000 r:1000 s:1000 P_SUGID:1)(e:1000 r:0 s:0 P_SUGID:0) [22. unpriv1 on daemon1].sched: expected EPERM, got 0 (e:1000 r:1000 s:1000 P_SUGID:1)(e:1000 r:0 s:0 P_SUGID:0) [23. unpriv1 on daemon1].signal: expected EPERM, got 0 (e:1000 r:1000 s:1000 P_SUGID:1)(e:1000 r:0 s:0 P_SUGID:1) [23. unpriv1 on daemon1].sched: expected EPERM, got 0 (e:1000 r:1000 s:1000 P_SUGID:1)(e:1000 r:0 s:0 P_SUGID:1) Each test case considers two processes with specially configured credentials, with the first process performing an operation on the second process. A table of "correct" values is included in the regression test, and the above output is generated where my expectations are not met by the implementation (not necessarily a sign that it's wrong, possibly a sign that my expectations are improper). In any case, I figured it was worth raising these cases for discussion. You can read a test by looking at the two lines associated with test output: the first identifies the test performed, as well as the difference in opinion of return value. The second prints out the contents of the subject and object credentials, where subject means the process requesting the operation, and object means the process on the receiving side of the operation. In each case above, the test scenario is one similar to that of a privileged daemon which temporarily takes on the effective identity of an unprivileged process, probably for the purposes of delivering a message, managing a spool file, etc. The test involves a second process, running with the real and effective credentials of the unprivilged user, attempting to act on the daemon process, which runs with privilege but has temporarily changed its effective identity to the unprivileged user's. In the above failure cases, the unprivileged process successfully performs a SIGHUP delivery to the daemon process, or invokes setpriority() on the process. Due to the nature of the testing engine, each test is performed a number of times with various permutations of the P_SUGID bit being set on the subject and object. For the purposes of this discussion, we're probably interested only in tests where P_SUGID is set on the object. Generally speaking, I would argue that it would be inappropriate for the unprivileged process to be able to perform these operations on, say, an lpd switched to its uid, to a web server in the same situation, sendmail during delivery, or ftpd. As such, I'd be tempted to introduce new restrictions in p_cansignal() and p_cansched() to require that the real uid be the same in the event that the effective uid's differ (with the exception of SIGCONT, which is always permitted if the sessions of the processes are the same, or if the subject credential has appropriate privilege). However, there may be situations where this is inappropriate, possibly involving SIGIO delivery or the like. Does anyone else have any reservations about making such a change? I have not implemented it yet, but it would probably be fairly straight-forward to do. On the other hand, I'd rather not break things too much in the process (a little is acceptable however). Hopefully in the near future, I (or someone else with time on their hands) will be expanding the regression tests to test other signals, add ktrace() and procfs debugging attach. 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-audit" 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.1010412001239.97720C-100000>