SELinux-Refpolicy Archive on
 help / color / Atom feed
* Are we on the wrong track?
@ 2020-06-12  0:03 Russell Coker
  2020-06-12  7:05 ` Topi Miettinen
                   ` (3 more replies)
  0 siblings, 4 replies; 21+ messages in thread
From: Russell Coker @ 2020-06-12  0:03 UTC (permalink / raw)
  To: selinux-refpolicy

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.

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?

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?

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 

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?

My Main Blog
My Documents Blog

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, back to index

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

SELinux-Refpolicy Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index selinux-refpolicy

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone