Re: Are we on the wrong track?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/11/20 8:03 PM, Russell Coker 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.

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.

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.

 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.

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.

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.

--
Chris PeBenito



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux