All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominick Grift <dominick.grift@defensec.nl>
To: Russell Coker <russell@coker.com.au>
Cc: selinux-refpolicy@vger.kernel.org
Subject: Re: staff_r
Date: Wed, 13 May 2026 13:20:21 +0200	[thread overview]
Message-ID: <87zf23imiy.fsf@defensec.nl> (raw)
In-Reply-To: <3505047.e9J7NaK4W3@dojacat> (Russell Coker's message of "Wed, 13 May 2026 21:04:03 +1000")

Russell Coker <russell@coker.com.au> 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.

Practically that makes staff_r useful for confined
administration. Whereas user_t is not useful for that because user_t
cannot gain root.

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.

>
> 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.

-- 
gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

  reply	other threads:[~2026-05-13 11:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13 11:04 staff_r Russell Coker
2026-05-13 11:20 ` Dominick Grift [this message]
2026-05-13 14:21   ` staff_r Russell Coker
2026-05-13 15:15     ` staff_r Dominick Grift

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zf23imiy.fsf@defensec.nl \
    --to=dominick.grift@defensec.nl \
    --cc=russell@coker.com.au \
    --cc=selinux-refpolicy@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.