SELinux-Refpolicy Archive on lore.kernel.org
 help / color / Atom feed
From: Russell Coker <russell@coker.com.au>
To: Chris PeBenito <pebenito@ieee.org>
Cc: selinux-refpolicy@vger.kernel.org
Subject: Re: Are we on the wrong track?
Date: Fri, 12 Jun 2020 23:02:55 +1000
Message-ID: <2469682.qIgoumM3a6@liv> (raw)
In-Reply-To: <578d7c7c-cb41-b224-2758-144aa9b5c1ad@ieee.org>

On Friday, 12 June 2020 10:52:56 PM AEST Chris PeBenito wrote:
> > 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?
> 
> I find this a valid criticism and reason enough to at least collapse them
> into a single domain.  The original intent was to constrain the special
> access they use, but you are correct, a compromised generator could do
> mostly do all the bad things anyway since it can write unit files.

OK, I'll submit a patch for that.

> > 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?
> 
> Yes.
> 
> >  Why is staff_wm_t needed when we no
> > 
> > longer have staff_gpg_t?
> 
> Sounds like a gpg change that should be reverted.

I had some of that in the Debian policy, it's a pain to maintain.

> >  Does staff_r even make sense when you could just use
> > 
> > different MCS categories for different users?
> 
> Yes, as user_r cannot reach admin roles whereas staff_r can.

The user identity has a permitted list of roles, you can have users who are 
permitted user_r and sysadm_r and users who are only permitted user_r.  The 
original benefit of staff_r was to protect staff from attacks by user_r 
accounts, but we can do that protection with the identity based constraints.

> > 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.
> 
> I'm a bit hazy on the details you're referring to but you're right that
> games_t may not be too impactful. Dominick's flatpak/sandbox/container
> approach may make more sense.  I don't have any recent Linux gaming
> experience (with Steam or otherwise) to judge.

Experience playing games isn't really required.  The situation is we have 
games_t assigned to a bunch of programs that come from the distribution and 
therefore meet certain minimum quality checks (which probably give the 
binaries in question a range of integrity that overlaps the contents of /usr/
sbin).  We also have games downloaded from steam which don't have source 
available and can't be reviewed for quality.  Also steam games are probably 
going to need DRI access which makes it extra exciting.

> > 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?
> 
> I'd be fine dropping the instantiaton of *_cronjob_t (except
> system_cronjob_t) but not removal of the template, for the few instances
> that users need it.
> 
> My question to you is why aren't you commenting on these changes as they are
> submitted, instead of unloading on the changes years after the fact? 
> You've been around the SELinux community longer than I have. These changes
> aren't merged in secrecy.

I have commented on some of these things in the past (I rejected *_cronjob_t 
for Debian).  We can deal with some inefficiency, but it builds up and now is 
at the stage where I think we have to revisit some assumptions that were made 
years ago.

-- 
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
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 [this message]
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=2469682.qIgoumM3a6@liv \
    --to=russell@coker.com.au \
    --cc=pebenito@ieee.org \
    --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