From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.sws.net.au (smtp.sws.net.au [144.76.186.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A6F2E2F7AD2 for ; Wed, 13 May 2026 14:22:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=144.76.186.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778682131; cv=none; b=QoPXmw+kX3Yfr02H10pcZp4IU1bPseATq7vCCihI2OhZJ13Kzb6lSANrPxBLCtwQ4WCm814NKHghbhRIDGNlcZMGQgd7FJXRry9hfp3VMU1tC0SFEitJWEwnlKpIteoVJ39Bx+B7G97MCbX8jawfvD2TMGSYK1643/qI+doLsSI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778682131; c=relaxed/simple; bh=I5W3raFN/wLY8c+sZuuBAca01iS5xOo5txjMfvCeUQg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=E6S8ZhZNoBDG6r+Dwv2Uq/LFjHuHr5zADW4FYW+3oTn5RqblNcEtjU/wR4BbSocpP7WLpbHkUJP960CaK9jiX5jsT8YMnSWO0X9ikX15xRQhIB0fwh14AUNextNFuflpEgyx7pzQsurnx4qyexeDHdOC+o7EumsuvlwI0FrzUrM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=coker.com.au; spf=pass smtp.mailfrom=coker.com.au; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b=rVWS5fwg; arc=none smtp.client-ip=144.76.186.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=coker.com.au Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=coker.com.au Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b="rVWS5fwg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1778682127; bh=oaN/dQ6epaCWvDR0BPMol046/BOKw/kmA+pheqmuweQ=; l=5006; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rVWS5fwgQGA7GyF16OmBHGpWTtByVMfUEeL13XERYcE2UfQNpWPxf6RCGOqCHxvKZ XkPn2yVrYUMFCe2IWcuVLuHsVEmuaUDIl1scSDgyvKx3hovAF5c08g66RHWWo9yKLP +6VHpJAwR36IRkW8fLomNCHB6MyY87qh52jx8Brw= Received: from liv.coker.com.au (unknown [IPv6:2001:4479:4300:6400:8e17:93c7:3fa2:324e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) (Authenticated sender: russell@coker.com.au) by smtp.sws.net.au (Postfix) with ESMTPSA id 82F3EFFDA; Thu, 14 May 2026 00:22:06 +1000 (AEST) From: Russell Coker To: Dominick Grift Cc: selinux-refpolicy@vger.kernel.org Subject: Re: staff_r Date: Thu, 14 May 2026 00:21:58 +1000 Message-ID: <23103313.EfDdHjke4D@dojacat> In-Reply-To: <87zf23imiy.fsf@defensec.nl> References: <3505047.e9J7NaK4W3@dojacat> <87zf23imiy.fsf@defensec.nl> Precedence: bulk X-Mailing-List: selinux-refpolicy@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" On Wednesday, 13 May 2026 21:20:21 AEST Dominick Grift wrote: > Russell Coker writes: > > Is there any point to staff_r? > > > > Currently it is a long way from usable for GUI sessions. > > > > For terminal sessions the isolation between staff_r and user_r is matched > > by the isolation between user identities. > > The idea, I believe, is that the difference between user_t and staff_t > is that the latter has access to privileges via su, sudo and > etc. staff_t is user user_t with access to root. My idea when I created staff_r was to have a role that's protected from user_r but not with the full access of sysadm_r. If MCS was a thing then I would have just used different categories. Logging in via ssh to staff_r and then "newrole -r sysadm_r" was a thing. At least one "Play Machine" was broken due to allowing "newrole -r sysadm_r" from user_r, but I'm not aware of any scenarios in which a staff_r is needed in real life since MCS became a thing. The uses of things can evolve so it would be possible to have certain roles only used for su/sudo, but in the current policy they are all allowed it. auditadm.te: sudo_role_template(auditadm, auditadm_t, auditadm_application_exec_domain, auditadm_r) secadm.te: sudo_role_template(secadm, secadm_t, secadm_application_exec_domain, secadm_r) staff.te: sudo_role_template(staff, staff_t, staff_application_exec_domain, staff_r) sysadm.te: sudo_role_template(sysadm, sysadm_t, sysadm_application_exec_domain, sysadm_r) unprivuser.te: sudo_role_template(user, user_t, user_application_exec_domain, user_r) auditadm.te: su_role_template(auditadm, auditadm_t, auditadm_application_exec_domain, auditadm_r) secadm.te: su_role_template(secadm, secadm_t, secadm_application_exec_domain, secadm_r) staff.te: su_role_template(staff, staff_t, staff_application_exec_domain, staff_r) sysadm.te: su_role_template(sysadm, sysadm_t, sysadm_application_exec_domain, sysadm_r) unprivuser.te: su_role_template(user, user_t, user_application_exec_domain, user_r) > Practically that makes staff_r useful for confined > administration. Whereas user_t is not useful for that because user_t > cannot gain root. auditadm.te: sysadm_role_change(auditadm_r, auditadm_t) secadm.te: sysadm_role_change(secadm_r, secadm_t) staff.te: sysadm_role_change(staff_r, staff_t) It can gain root but only auditadm_r, secadm_r, and staff_r can get sysadm_r. The staff_t domain has a handful of extra sysadmin type permissions such as corenet_ib_access_unlabeled_pkeys(), why does it have that? Also that corenet_ib_access_unlabeled_pkeys() interface is just a wrapper for kernel_ib_access_unlabeled_pkeys() - why? Is staff_r supposed to be used for graphical logins or just for text based admin tasks? What about sysadm_r is that supposed to be used for graphical tasks like evolution_role() and gnome_role_template() as well as things like games_role() and irc_role()? > These days things are more complicated with other ways to gain > privileges like policykit and others but the essence is, AFAIK, still > the same and even though systemd and others can leverage policykit even > in a non-gui environment it is still optional functionality. One of the advantages of SE Linux is the ability to analise rules. But as such analysis is based on domain/type not on identity and role we can't see the distinction between different roles (which don't make it to labels for objects). So when you have staff_r and user_r using the same types for home directories etc you have to just know that only the identity keeps them apart. > > The role transition rules generally aren't used for anything and the roles > > permitted to an identity determine what role transitions can be used. > > > > The vast majority of use of the reference policy is for "targeted" > > configurations without even using user_r. > > > > Is there any reason for keeping staff_r? > > Reference policy is a hybrid between strict and targeted. You can remove > or disable the targeted aspect and effectively enforce a strict policy > and this is where these confined login user domains are essential. You have to remove the unconfined module to have fully confined users. The mono_t and wine_t domains can be entered from user_t and are unconfined. So the limitations on user_t when you have the unconfined module loaded and wine or mono installed are those which the wine and mono runtimes decide to put in place. The problem we have is that we have a lot of roles with no plans that haven't been lost to time and no documentation that I'm aware of. So we have *_admin interfaces called from sysadm.te for all the daemons that were around when we transitioned to modular policy (which makes sysadm.te larger than all the other role files combined) but no such interfaces for newer domains. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/