-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide barebones versions of existing domains #328
Comments
What permissions allowed on There use to be a 'base domain" that didn't have any of the permissions added on domains, but only kernel threads used it, and we didn't feel the distinction provided real value. |
Mostly ioctl and socket permissions, but I honestly want to be able to say, “this program gets exactly what it needs and nothing else.” I want to lock down a process so tightly that if I removed even a single permission, the process would not be able to perform its intended task.
It’s also worth noting that I tend to avoid using interfaces, as they often grant unnecessary permissions. I prefer to use |
It does not seem that Refpolicy is a good choice for your needs. What you're stating as excessive are considered reasonable tradeoffs to improve readability and maintainability in refpolicy. Interfaces allowing a process that needs to If you have specific criticisms for rules that are applied to |
Chris PeBenito <notifications@github.com> writes:
It does not seem that Refpolicy is a good choice for your needs. What you're stating as excessive are
considered reasonable tradeoffs to improve readability and maintainability in refpolicy. Interfaces allowing
a process that needs to write a file to also getattr, a typical operation to determine file existence, and
to append, a subset of write access, fits the dictionary definition of excessive, but it is not considered
excessive in refpolicy. This type of tradeoff is made throughout the policy.
If you have specific criticisms for rules that are applied to domain or daemon, I'll be happy to consider
them, but I'm not yet convinced a base domain needs to be brought back.
The issue I have with domain versus for example other low level
attributes like file_type are the neverallow rules associated with
domain making domain essentially mandatory for processes.
The allow rules referencing domain as a source are relatively few but
there are also allow rules that reference domain as a target and one
might want to be able to override those.
That said, I do agree that its all about compromising. Implementing this
with CIL is much easier and therefore more compelling.
…
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
--
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
|
Those are fine. The main permission I don’t like is |
There are several other limitations I have noticed:
|
This is intentional, at a minimum so you don't have a domain transitioning to a non-domain.
If you're referring to
Can you provide examples? I don't remember anyone reporting regressions. |
One further note, the |
Chris PeBenito <notifications@github.com> writes:
The issue I have with domain versus for example other low level attributes like file_type are the
neverallow rules associated with domain making domain essentially mandatory for processes.
This is intentional, at a minimum so you don't have a domain transitioning to a non-domain.
I know that this is intentional but in my view that aspect could warrant
a base domain. So that the neverallow rule can be associated with the
base domain but not any other "optional" rules common to domain.
…
* init_t is distinct from unconfined_t, but there is no such distinct type for user systemd instances.
If you're referring to systemd --user instances, this is inaccurate. There are domains for each confined
domain, e.g. staff_systemd_t. For unconfined_t, the systemd --user will run as unconfined_t.
* Confined user support often regresses.
Can you provide examples? I don't remember anyone reporting regressions.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
--
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
|
@doverride exactly. If I want to transition to a type with absolutely no privileges, I should be able to. |
These are the ioctls that are provided by
|
Other than maybe revoking the ioctl on urandom, I'm still not convinced for a base domain need. |
Chris PeBenito <notifications@github.com> writes:
Other than maybe revoking the ioctl on urandom, I'm still not convinced for a base domain need.
truth be told i do not use my base domain much either but container processses
and the kernel threads are some of the exceptions.
For example a container does not need access to the devices you
mentioned in your ioctl email. Instead the APT fs is mounted with a
special container type.
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
--
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
|
And so what if it has that access? Why add more policy complexity to stop a container from accessing /dev/null, for example? |
This seems like a fairly sensible argument in my view. However, I'm somewhat concerned about the usability issues where now rules of the form "allow foo domain:process { some_perms };" don't actually apply to all processes on the system. It seems to me as though there are two potential goals here:
I understand the desire to be strictly least privilege, but it seems like in the current architecture, you'd have usability problems around point 2 above. My inclination would be that if there's some sort of expansion, we might want separate attributes for each of those two cases depending on the security goals, but then you're adding even more complexity. If I'm understanding the original request correctly, it's really more about point 1 I believe. In that scenario, I'd think you'd want all existing access with target domain to still apply to this bare domain. That's something that would be a lot easier to implement in CIL than in existing refpolicy I think. |
Chris PeBenito <notifications@github.com> writes:
And so what if it has that access? Why add more policy complexity to stop a container from accessing
/dev/null, for example?
Theres a few conciderations here:
1. The ability to omit access to those common devices like /dev/null is
just a nice side effect, to me its about the bigger picture (to sum of
all the rules associated with domain).
2. If you have a bare domain at the your disposal then you *can* use it
if you like (so i do it because i can do it)
3. If you have the above flexiblity then you can make the non-base
domain a bit more useful for "common domains". ie. for example associate rules that allow
access to generic libraries. (this could lead to more efficient policy)
In the end its just nice to have the option to by-pass domain without
breaking the neverallow assertion.
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
--
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
|
True, but that is also the point. It is the ability to by-pass and the bare domain should only be used where you really want the process to be treated unlike common processes (that is also why i don't use it much but i still like having the option)
In my policy I have "subj" and "common subj" where "subj" is used to just associate the neverallow so that the policy will not build there is a transition rule associated with a type that is not either subj or common subj. common subj is a superset of subj and in my policy i associate various rules with that type that apply to common processes. So i use it a bit more extensively. For example using generic libraries is something i allow on this low level for efficiency. So i admit that my use case isnt completely comparable to refpolicy.
I think so to and i do understand the concerns. I just think that one might be able to squeeze more out of the low level domain concept. but if not then its not a big deal since domain is currently almost nothing. There are probably more rules referencing domain as a target than there are rules referencing domain as a source |
Actually, it is the ioctls on regular files and sockets that I am more worried about. Those have a much larger attack surface, and many of them are quite obscure so I suspect they do not see much testing. In particular, there have been quite a few cases where Android was saved because SELinux blocked an obscure and vulnerable socket ioctl. Personally, I would like to have these classes:
|
|
This issue has not had any recent activity. It will be closed in 7 days if it makes no further progress. |
IIRC there was a (now fixed) vulnerability in an f2fs ioctl found by syzbot a while back. I suggest starting with ioctls that are filesystem specific, as I expect most applications have no need to know what filesystem they are running on. |
Ok, I'm only marginally convinced on this still. However, since this is a simple change I'll do it anyway. I will be equally skeptical for patches/PRs making anything in refpolicy a base domain. |
I forgot that @DemiMarie please try the above PR and see if it meets your needs. |
This issue has not had any recent activity. It will be closed in 7 days if it makes no further progress. |
Closing stale PR. |
Currently,
domain
adds more permissions than are actually needed.It would be nice to have a type (
barebones_domain
?) that includes exactly the permissions needed to run a program that does nothing, and no more. Similarly, there would be abarebones_daemon
with the minimum permissions for a daemon that just immediately exits, and so on.This would be useful for those who want a strict default-deny policy, since it ensures that access is not accidentally granted.
The text was updated successfully, but these errors were encountered: