SELinux-Refpolicy Archive on
 help / color / Atom feed
From: Dominick Grift <>
To: Russell Coker <>
Cc: refpolicy <>
Subject: Re: Are we on the wrong track?
Date: Fri, 12 Jun 2020 14:26:35 +0200
Message-ID: <> (raw)
In-Reply-To: <11621688.XNj53QmPYG@liv> (Russell Coker's message of "Fri, 12 Jun 2020 22:05:45 +1000")

Russell Coker <> writes:

> On Friday, 12 June 2020 8:15:34 PM AEST Dominick Grift wrote:
>> What was the main part of your message than? The complexity involved
>> with removing modules you do not need in any given configuration?
> The difficulty in managing it all and the limited benefit in trying to do it.

Yes, Its a bit easier with CIL policy and maybe could even be automated
in an environment that leverages CIL (although not sure if that would be worth the overhead)

>> >> I suppose it's a generic domain for window managers. It originates
>> >> from the metacity day's Things changed quite a bit since then (think
>> >> wayland compositors)
>> > 
>> > Are you saying we should remove the staff_wm_t?
>> I am just sharing my knowledge. I will leave that decision to others.
> To know how something it works is to know whether it works well enough or 
> should be improved.

I think its subjective.

Maybe there no longer is a need to derive wm_t. We would need to
identity why wm_t was derived in the first place.

Maybe its worth it to make a distinction between X window managers and
Wayland window managers (although its not as simple i guess due to the
Xwayland compatibility layer)

I guess I will just admit that I don't feel qualified to answer this question.

>> > I think roles could have always been used for that.  But adding lots of
>> > roles used to be a lot easier.
>> No, the defaultrole functionality is relatively new.
> Before modular policy when the entire policy was compiled in m4 on every 
> system it was very easy to change roles.

That was before my time (at least I cannot remember), but I have my

>> > So I guess we could have 3 base domains for users, user_t, sysadm_t, and
>> > unconfined_t.  We could then have roles user_r and staff_r both suitable
>> > for user_t and similar domains and have unconfined_r and sysadm_r for
>> > unconfined_t and sysadm_t respectively.
>> > 
>> > Another possibility would be to remove unconfined_r, have
>> > sysadm_r:sysadm_t be for unconfinbed users, it will be literally
>> > unconfined if the unconfined module is installed and just like sysadm_t
>> > is now otherwise.
>> In dssp3 I take this to another level. The concept of exemption is
>> embraced, and the need for trust is acknowledged (yes that one was tough to
>> swallow).
>> There is no unconfined_t in dssp3. there is just "the system" and "the
>> system" is trusted and exempted. This simplifies the policy a great deal
>> since there isn't a number of unconfined domains by default, there is
>> just one trusted context by default (you can still make additional
>> domains unconfined but that is discouraged)
> So you have init, getty, and syslogd all running in the same context?

Stuff that runs in "the system" context (is trusted):

1. systemd --system (pid1)
2. systemd-tmpfiles --system
3. dbus --system
4. default login shells
5. package managers
6. unknown system services

(i might have overlooked some)

> I've been considering how we might make a usable system that includes Biba.
>> >> > We have one games_t domain for games which were packaged by the
>> >> > distribution. Is this possible to give a useful benefit given that they
>> >> > some games the same XDG config directories as more important things. 
>> >> > If
>> >> > a game has the file access needed to grab passwords from your MUA and
>> >> > network access to send them out then is there a real benefit in having
>> >> > a
>> >> > separate domain for it?  As an aside I think that the ideal thing to do
>> >> > would be to have a SETGID program to manage passwords for email etc
>> >> > that
>> >> > prevents the user from accessing them, it could then proxy IMAP/SMTP
>> >> > connections so the MUA never knows the real passwords.
>> >> 
>> >> That's generalizing.
>> > 
>> > We are trying to write policy that is generally usable.
>> I dont think games should have access to MUA
> Yes.  But if we have game data stored in the same places as MUA data then it 
> happens.  A policy to make warzone2100 work in Debian allows games_t to access 
> MUA data.
>> >> But as for games. Today things like flatpak might be more  suitable.
>> >> Then you can combine SELinux and other kernel tech like namespaces,
>> >> bind mounts to make stuff inaccessible etc. Theres also steam which
>> >> essentially is a dumb version of flatpak. I don't think steam would
>> >> ever need any access to a MUA and any of its assets
>> > 
>> > Steam needs full network access, graphics, sound, and XDG directory
>> > access.
>> Yes but you were using "passwords" as an argument and then some how put
>> MUA into the equation (I honestly have no clue why a game would need
>> access to a MUA). Not to mention that when it comes to passwords (and to
>> authentication) there are better way's to secure access. Think for example
>> smartcards, TFA, encryption, etc.
> What's a good way of setting up TFA with IMAP on both client and server?  With 
> most systems that have TFA you have a single password for IMAP and TFA for the 
> management (changing calendar, plugins, etc).
> If MUA is too controversial I could find some other example of something under 
> ~/.local that games probably shouldn't access.

Take for example my mutt and gnus configuration.
You can GPG encrypt the passwords, then use your smartcard to decrypt
the passwords on demand (your smartcard requires a pin and a hardware

I also do similar with my borg backup config:

export BORG_PASSCOMMAND='pass show borgbackup'

where pass is a shell script that basically leverages gpg/smartcard to
decrypt passwords on the fly. (You need a PIN and a smartcard)

>> >> module policy and monolithic policy are just too limited compared to
>> >> CIL, and refpolicy has some designs centered around things that just
>> >> don't work (think about the derived types limitation i mentioned above
>> >> and how that is rooted to the core in refpolicy (example staff_dbusd_t
>> >> and the dbus_role_template effectively make dbus a hard dependency
>> >> (effectively nowaday's it is) but this also means that no dbus role
>> >> templates (and this any dbus interfaces) should ever be in optional
>> >> blocks
>> > 
>> > We can change some of these things.
>> I guess the question is whether it is worth the investment. I will leave
>> that decision to others.
> I think the decision might be whether it's worth continuing to maintain 
> refpolicy or whether it should be obsoleted.

gpg --locate-keys
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

  reply index

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12  0:03 Russell Coker
2020-06-12  7:05 ` Topi Miettinen
2020-06-12  8:02 ` Dac Override
2020-06-12  9:54   ` Russell Coker
2020-06-12 10:15     ` Dominick Grift
2020-06-12 12:05       ` Russell Coker
2020-06-12 12:26         ` Dominick Grift [this message]
2020-06-12 12:53           ` Russell Coker
2020-06-12 13:20             ` Dominick Grift
2020-06-14 16:30             ` Topi Miettinen
2020-06-12 11:00 ` Denis Obrezkov
2020-06-12 11:53   ` Russell Coker
2020-06-12 11:57   ` Dominick Grift
2020-06-12 12:52 ` Chris PeBenito
2020-06-12 13:02   ` Russell Coker
2020-06-12 14:03     ` bauen1
2020-06-15 13:52     ` Chris PeBenito
2020-06-15 21:02       ` Russell Coker

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:

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

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

SELinux-Refpolicy Archive on

Archives are clonable:
	git clone --mirror selinux-refpolicy/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux-refpolicy selinux-refpolicy/ \
	public-inbox-index selinux-refpolicy

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone