SELinux-Refpolicy Archive on lore.kernel.org
 help / color / Atom feed
From: Russell Coker <russell@coker.com.au>
To: Dominick Grift <dominick.grift@defensec.nl>
Cc: refpolicy <selinux-refpolicy@vger.kernel.org>
Subject: Re: Are we on the wrong track?
Date: Fri, 12 Jun 2020 22:53:33 +1000
Message-ID: <3403154.DDNKOWLi4p@liv> (raw)
In-Reply-To: <ypjl5zbwpj0k.fsf@defensec.nl>

On Friday, 12 June 2020 10:26:35 PM AEST Dominick Grift wrote:
> 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)

What exactly are you saying could be automated?

> >> >> 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 just noticed that user_wm_t policy is in Debian/Buster, but I never noticed 
it because the type label for KDE wasn't setup.

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

Why be so different?  Why not system_u:system_r:base_sys_t: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)

There is the argument about minimum privs.  The minimum privilege extremists 
want to have things like compilers locked away, I disagree with that as a 
hostile party probably would have their own binaries ready.  But restricting 
who can run the package manager to install things seems useful, more useful 
than having 32 different executable types as parts of systemd (not kidding, I 
ran wc).

Most of my refpolicy development time is spent adding rules for extra domains 
that people have added and for extra systemd features.

-- 
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 [this message]
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=3403154.DDNKOWLi4p@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

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