Denis Obrezkov <denisobrezkov@xxxxxxxxx> writes: > Hi, Russell, Not Russell but allow me... > > I am a novice in SELinux, even though I am learning it for a year or so. > And I can't really understand why SELinux is SO complex. Not only the > policy, but the whole SELinux. In time i've learned to appreciate the simplicity and elegance of SELinux given the tasks it accomplishes. I acknowledge that it may take some time for one to see that "light". > For example, there are two different ways of writing a policy - CIL and There are actually 4 different way's of writing a policy. It's evolution. 1. Monolitic policy 2. Modular policy 3. Reference policy 4. Common Intermediate Language > the other one. And they have conflicting namesets (typeattribute = > atttribute). At the same time, this behavior is just slightly > documented. One can't create a policy only using information from docs. I suspect that when the "attribute" statement was created no one had foreseen that we eventually would end up with not just a "type attribute" but also with a "user" and "role' "attribute". CIL merely corrected this by renaming it all in a more consistent way where the existing languages were unable to rename it for compatibility reasons: CIL: 1. typeattribute 2. roleattribute 3. userattribute Old: 1. attribute 2. attribute_role 3. (not even sure is user attributes are supported in anything but CIL) > At the same time, some parts of SELinux are very unstable. Like, MCS. It Creating a policy (from scratch) is indeed not very well documented AFAIK. There is however a script in the kernel documentation tree called MDP that creates a simple policy. This script can be used to get at least some idea of what it takes to write a policy. > was introduced and it is used only for VM management. And mcstransd is Not everyone will agree with me probably but to me MCS was alway's a "hack" to make some use of MLS in systems that do not enforce confidentiality. The term hack here is meant in a good way: to highlight how flexible SELinux is. MCS also evolved over time, and eventually I think the current implementation of this "hack" is the most useful. It may (or may not) by known as "SVIRT" but really its just a technique to use the compartments of MLS to accomplish seperation and the use case for this is actually broader than you may think. The usuability of MCS might also be easier than you think. I played with MCS just the other day to separate python web application containers with gunicorn/django and systemd/systemd-portable and it just works for me. No need for mcstransd. mcstransd is really only used in some MLS environments where the levels need to be human readable. This is not a requirement for common MCS seperation. mcstransd just adds overhead. > bad. It's really bad. I was trying to use it and it was totally > unstable. So, even if someone wants to use MCS - it is almost impossible > because tools are unstable and MCS is already almost exclusively used by > VMs. > > On 12.06.20 02:03, 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? >> >> 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 >> passwords. >> >> 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? >> -- gpg --locate-keys dominick.grift@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
