From owner-freebsd-bugs@FreeBSD.ORG Sun Apr 7 21:50:01 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C69298A9 for ; Sun, 7 Apr 2013 21:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id ACD211CF for ; Sun, 7 Apr 2013 21:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r37Lo1Ol099984 for ; Sun, 7 Apr 2013 21:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r37Lo1xj099983; Sun, 7 Apr 2013 21:50:01 GMT (envelope-from gnats) Resent-Date: Sun, 7 Apr 2013 21:50:01 GMT Resent-Message-Id: <201304072150.r37Lo1xj099983@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Kevin P. Barry" Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2097D703 for ; Sun, 7 Apr 2013 21:44:52 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 11BAF18A for ; Sun, 7 Apr 2013 21:44:52 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.5/8.14.5) with ESMTP id r37Lip4K049585 for ; Sun, 7 Apr 2013 21:44:51 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.5/8.14.5/Submit) id r37LipIn049584; Sun, 7 Apr 2013 21:44:51 GMT (envelope-from nobody) Message-Id: <201304072144.r37LipIn049584@red.freebsd.org> Date: Sun, 7 Apr 2013 21:44:51 GMT From: "Kevin P. Barry" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 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. X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 21:50:01 -0000 >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: