From nobody Sun May 30 01:57:10 2021 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 31DBEC7C157 for ; Sun, 30 May 2021 01:57:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ft1kt0hZrz3Cpw for ; Sun, 30 May 2021 01:57:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id F224A14F43 for ; Sun, 30 May 2021 01:57:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 14U1v9tF037446 for ; Sun, 30 May 2021 01:57:09 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 14U1v9WU037445 for ports-bugs@FreeBSD.org; Sun, 30 May 2021 01:57:09 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 256233] security/doas: target user's login class gets ignored Date: Sun, 30 May 2021 01:57:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bugs.freebsd@scourger.nl X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256233 --- Comment #2 from bugs.freebsd@scourger.nl --- Thanks for the quick reply. I've done a little bit of extra testing, and ca= me up with some points and opinions. Regarding su, doas actually doesn't behave in the same way as su in my test= s. While su also ignores the target user's login class, it does keep the capabilities of the caller intact. Conversely, doas applies capabilities fr= om the "default" class. To demonstrate that su just leaves the caller's limits intact: alice@doas-bug:~ $ su bob -c 'ulimit -m' Password: 8388608 alice@doas-bug:~ $ su bob -c 'locale | grep LANG' Password: LANG=3Den_CA.UTF-8 ## On OpenBSD To compare what happens on OpenBSD, I have done a clean install of OpenBSD = 6.9 (in a VM) with similar limits configured for alice and bob. This yields some interesting results: alice@openbsd $ ulimit -m 8388608 alice@openbsd $ su bob -c 'ulimit -m' 4194304 alice@openbsd $ doas -u bob ulimit -m doas: ulimit: command not found alice@openbsd $ doas -u bob sh bob@openbsd $ ulimit -m 4194304 1. In contrast to FreeBSD, su also applies limits from the target user's lo= gin class. This difference in behaviour came somewhat as a surprise to me. 2. Interestingly, OpenBSD doesn't let you run "doas ulimit" (another surpri= se). But "doas -u bob sh" seems to indicate that limits from bob's login class a= re applied. 3. On OpenBSD, behaviour between doas and su is consistent. Note: apparently OpenBSD doesn't let you configure "lang" in /etc/login.con= f, so it has been omitted here. ## My opinion All things considered, this is my take on the issue: * By default, doas should either apply the target user's login class (as is= the case on OpenBSD) or keep the capabilities of the caller (like su on FreeBSD= ). In the current situation doas always applies the "default" login class, whi= ch I'd consider incorrect in any case. * For me personally, I'd prefer the same behaviour as on OpenBSD (apply tar= get user's login class). A clear downside of this approach is that it would make doas inconsistent with su. But in my opinion, OpenBSD's su behaviour also m= akes more sense (apply target user's limits) compared to FreeBSD. * I do not consider it likely that the behaviour of su on FreeBSD will be changed anytime soon, so changing doas to just keep the callers capabilities seems like a very reasonable thing to do. This way, doas and su work consistently. Depending on who you'd ask, this could be intended behaviour = or still not correct. * As for "doas -S", I think it should indeed be identical to "su -l". This whole issue does make me wonder about the proper/intended behaviour of= su. --=20 You are receiving this mail because: You are the assignee for the bug.=