SELinux-Refpolicy Archive on lore.kernel.org
 help / color / Atom feed
From: Russell Coker <russell@coker.com.au>
To: Dac Override <dac.override@gmail.com>
Cc: refpolicy <selinux-refpolicy@vger.kernel.org>
Subject: Re: Are we on the wrong track?
Date: Fri, 12 Jun 2020 19:54:35 +1000
Message-ID: <3179073.KMaz8WPbdX@liv> (raw)
In-Reply-To: <CAJVWAV1oKcSB9dxFPD3As9-78JW4uSAcCN9jY8zsZdvspEC9aQ@mail.gmail.com>

On Friday, 12 June 2020 6:02:15 PM AEST Dac Override wrote:
> On Fri, Jun 12, 2020 at 2:16 AM Russell Coker <russell@coker.com.au> wrote:
> > The reference policy is getting an increasing number of domains and types
> > with an O(N^2) level of complexity for writing policy and an O(N^2) size
> > of the binary policy.  In 2012 the binary policy on my machines was 560k,
> > now it's over 2M.
> 
> The number of domains available by default should not be a problem if
> you can easily select which modules you want to use.
> with module policy this is not as easy as with CIL as the modular
> nature of module policy makes it harder to resolve dependencies
> (almost impractical). The human readable nature of CIL and iits "feels
> like modular but is really just monolithic" nature makes dependency
> resolving at runtime with CIL generall much easier (but there are
> still limitations).

As Topi noted there are ways of reducing the binary size.  But that was the 
minor part of my message.

> > In recent policy we have 6 different domains for systemd-generators.  What
> > benefit are we expecting to get from this?  Are we anticipating that one
> > generator will attack another?  How would having separate domains for
> > generators do any good when there's no restriction on the contents of the
> > files they generate and nothing to prevent one generator from creating a
> > file of the name that another generator is expected to create?  Is it
> > even reasonable to expect that a program that can create a systemd unit
> > file with arbitrary content (IE being able to start any daemon with
> > arbitrary configuration and command-line parameters) would be unable to
> > exploit that for unrestricted root access?
> 
> When push comes to shove, generators are just short-running services
> (ie its code run by systemd) generally (unit) generators do some
> enumeration and then create a runtime unit accordingly.but there have
> already been instances where this functionality has been "abused" (the
> dbus -> dbus-broker migration in fedora). In the end though, it might
> not be worth the trouble to target them. If you're allowed to write to
> the systemd runtime generator dir then you can drop a script , run
> systemd daemon-reload, and systemd will run that code.

Yes.

I just did some policy searches and found the following allowing access to 
init_runtime_t.  This probably isn't what we want.

allow ftpd_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ allow_ftpd_full_access ]:True
allow nfsd_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ nfs_export_all_rw ]:True
allow nmbd_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ samba_export_all_rw ]:True
allow puppet_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ puppet_manage_all_files ]:True
allow sftpd_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ sftpd_full_access ]:True
allow smbd_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ samba_export_all_rw ]:True

> > We have a new set of domains, user_wm_t, staff_wm_t, etc.  What is that
> > for? Is someone using the X controls and in need of a privileged window
> > manager domain to manage the clipboard etc?  Why is staff_wm_t needed
> > when we no longer have staff_gpg_t?  Does staff_r even make sense when
> > you could just use different MCS categories for different users?
> 
> 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?

> The derived types concept, originallly, i think, tackled the scenario
> where something needs to run either a shell or a cmmand on behalf of
> the caller and still run with private rules. This was quite an isssue
> in the recent past (for example pulseaudio clients would run
> pulseaudio on demand, pulse audio would run dbus on demand (i believe)
> and dbus would run potentially anything on demand (dbus activated
> services). So there was a dependency chain there to ensure some
> consistency.
> 
> Nowaday/s thats all gone, pulseaudio is systemd socket activated, dbus
> is system socket activated, and dbus activation is really just dbus
> telling systemd to start something (rather than dbus running the dbus
> activated command itself)

That sounds great, we can remove a bunch of policy for dbus stuff then.

> Another side effect of derived types is that it can be used for
> isolation of users sessions. Nowaday's roles can be used for this.

I think roles could have always been used for that.  But adding lots of roles 
used to be a lot easier.

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.

> Derived types, in practice, are bad because you cannot declare types
> reliably in optional policy. In effect that means that you cannot
> reliably use derived types for types that may be optional.
> 
> > 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.

> 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.
 
> > We have special *_cronjob_t domains which in systems that use them (IE not
> > Debian) seem to give the potential for nothing but confusion.  The general
> > expectation is that anything which can run as a user login session can
> > also
> > run as a cron job.  What benefit is this expected to provide?
> 
> the derived cronjob domains (with the exception of system_cronjob_t)
> are conditional. This functionality can be tuned and i think it's
> disabled by default.
> 
> There will always be legacy to carry, things change all the time. It
> is give and take. I don't think refpolicy has much of a future to
> forward to but not for the reasons above.

If the reasons I listed are a sufficient disincentive to contributing towards 
the refpolicy then it can limit the future of refpolicy.

Things currently aren't working well.  I'm thinking of just making changes 
similar to what I describe above and letting refpolicy upstream decide whether 
they want to do something compatible or whether we go separate ways.

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

> DSSP3 is my vision of what a modern policy should look like (except
> that it doesn't support enforcement of confidentiality)
> Eventually though DSSP3 will grow legacy just like refpolicy, I do not
> pretend otherwise.
> But a lot has changed and DSSP3 took the opportunity to rebuild for the new
> new.
> 
> Also with DSSP3 i learned from the bloat lesson. DSSP3 itself is
> intentionally kept small and concise.I acknowledge that  policy has to
> be maintained over time and so if you limit yourself to a relatively
> small set of types/roes/id etc and you focus on the quality of that
> then you make life easier.
> 
> I do have a "DSSP3 constrib" and this repository can and will has as
> many modules as needed (of course the quality of those modules cannot
> be vouched for) but they're all optional and self-contained (to the
> extent possible)

Sounds interesting.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/




  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 [this message]
2020-06-12 10:15     ` Dominick Grift
2020-06-12 12:05       ` Russell Coker
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-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=3179073.KMaz8WPbdX@liv \
    --to=russell@coker.com.au \
    --cc=dac.override@gmail.com \
    --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