Date: Sun, 7 Apr 2013 21:44:51 GMT From: "Kevin P. Barry" <ta0kira@gmail.com> To: freebsd-gnats-submit@FreeBSD.org Subject: bin/177698: [patch] sshd sets the user's MAC label at the same time it attempts to set the login class, which can cause the latter to fail if mac_biba is used. Message-ID: <201304072144.r37LipIn049584@red.freebsd.org> Resent-Message-ID: <201304072150.r37Lo1xj099983@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 177698
>Category: bin
>Synopsis: [patch] sshd sets the user's MAC label at the same time it attempts to set the login class, which can cause the latter to fail if mac_biba is used.
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Apr 07 21:50:01 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Kevin P. Barry
>Release: 9.1-RELEASE amd64
>Organization:
>Environment:
FreeBSD kpbarry 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Tue Mar 19 13:38:14 EDT 2013 root@kpbarry:/usr/obj/usr/src/sys/KPBARRY amd64
>Description:
When using the mac_biba module, only root processes that are capable of attaining biba/equal status are considered privileged. Among the privileges to be lost for processes that cannot attain biba/equal is the ability to set the login class of the process.
When sshd sets the user's context upon successful authentication (session.c:1494), both the user's login class and the corresponding MAC label are set in the same call to setusercontext. Since this isn't an atomic function, it's possible for the MAC label to be set before the login class (in my case, this certainly happens.) Therefore, if the login class of the user logging in has a MAC label in /etc/login.conf incompatible with biba/equal (e.g. biba/high(high-high)) then the login class might not be set (in my case it *doesn't* get set.) This can cause unexpected behavior for tools that can be configured by login class, e.g. rctl.
My proposed solution is to separate context-setting into two calls to setusercontext, with the first call setting all but LOGIN_SETMAC, and the second call setting only LOGIN_SETMAC. I've included a patch, which works on my system.
>How-To-Repeat:
- Enable mac_biba.
- Set the MAC label of a login class to ":label=biba/high(high-high):" in /etc/login.conf and run cap_mkdb. By default, sshd will probably run under the "default" login class; therefore, use a different login class so that a change in login class is required upon login.
- Log in remotely as a user who is a member of the login class modified in the step above. The login should succeed.
- Look at /var/log/messages for a message regarding setloginclass, and/or use `ps -o class -aux | grep sshd` to verify that the login class hasn't been set properly for the logged-in user.
>Fix:
Patch /usr/src/crypto/openssh/session.c so that the MAC label is explicitly set after the login class is set.
Patch attached with submission follows:
--- /usr/src/crypto/openssh/session.c.orig 2012-12-03 22:41:51.000000000 -0500
+++ /usr/src/crypto/openssh/session.c 2013-04-07 17:01:32.000000000 -0400
@@ -1491,11 +1491,24 @@
if (platform_privileged_uidswap()) {
#ifdef HAVE_LOGIN_CAP
+#ifdef LOGIN_SETMAC
+ /* Set the MAC label second so it doesn't interfere with setting the login class. */
+ if (setusercontext(lc, pw, pw->pw_uid,
+ (LOGIN_SETALL & ~(LOGIN_SETENV|LOGIN_SETPATH|LOGIN_SETUSER|LOGIN_SETMAC))) < 0) {
+ perror("unable to set user context");
+ exit(1);
+ }
+ if (setusercontext(lc, pw, pw->pw_uid,LOGIN_SETMAC) < 0) {
+ perror("unable to set user context");
+ exit(1);
+ }
+#else
if (setusercontext(lc, pw, pw->pw_uid,
(LOGIN_SETALL & ~(LOGIN_SETENV|LOGIN_SETPATH|LOGIN_SETUSER))) < 0) {
perror("unable to set user context");
exit(1);
}
+#endif
#else
if (setlogin(pw->pw_name) < 0)
error("setlogin failed: %s", strerror(errno));
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201304072144.r37LipIn049584>