From: Russell Coker <russell@coker.com.au>
To: Dominick Grift <dominick.grift@defensec.nl>,
refpolicy <selinux-refpolicy@vger.kernel.org>
Subject: Re: Are we on the wrong track?
Date: Fri, 12 Jun 2020 22:05:45 +1000 [thread overview]
Message-ID: <11621688.XNj53QmPYG@liv> (raw)
In-Reply-To: <ypjleeqkpp2x.fsf@defensec.nl>
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.
> >> 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 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.
> > 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?
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.
> >> 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.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
next prev parent reply other threads:[~2020-06-12 12:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-12 0:03 Are we on the wrong track? 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 [this message]
2020-06-12 12:26 ` Dominick Grift
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-07-16 14:09 ` Chris PeBenito
2020-07-19 19:29 ` bauen1
2020-07-21 14:22 ` Chris PeBenito
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=11621688.XNj53QmPYG@liv \
--to=russell@coker.com.au \
--cc=dominick.grift@defensec.nl \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).