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

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

>> > 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): sys.id:sys.role:sys.isid:s0

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)

>
> https://en.wikipedia.org/wiki/Biba_Model
>
> 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
token)

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 dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
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:
  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=ypjl5zbwpj0k.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

SELinux-Refpolicy Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux-refpolicy/0 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/ https://lore.kernel.org/selinux-refpolicy \
		selinux-refpolicy@vger.kernel.org
	public-inbox-index selinux-refpolicy

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux-refpolicy


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git