Re: Are we on the wrong track?

[Dominick Grift <dominick.grift@defensec.nl>]

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