Re: [RFC PATCH v3 2/5] lsm: introduce hooks for kdbus

On Mon, Oct 19, 2015 at 6:29 PM, Paul Moore <pmoore(a)redhat.com&gt; wrote: I think it would be simpler to apply an associate check when the endpoint is created between the endpoint label and the bus label (which will typically be the same), and then only check based on endpoint label for all subsequent permission checks involving that endpoint. Then you don't have to worry about which label to use for all the other permission checks. And you get finer-grained control - per-endpoint rather than only per-bus. In the common case, the labels will be the same and it won't matter, but if you want to support some MAC form of their 'custom endpoints' with further restrictions, you can do that by labeling the endpoints uniquely and using those labels in your permission checks. Otherwise, I have to ask whether you need two different classes above (bus vs endpoint), and whether the privileged/activator/monitor/policy permissions properly belong with the endpoint label or the bus label. At least some of those are bus-wide properties, not endpoint-specific, but that's ok as long as we have established a relationship between the endpoint label and bus label. Can you 'use' an endpoint in any way other than to connect via it? If not, I'd just call that connect (won't conflict if you get rid of the separate bus check above), or distinguish it via separate classes or as connectthrough vs connectto. conn->owner is used to determine whether the caller can fake credentials, skip kdbus policy checking, create an activator, monitor, or policy holder connection, etc. Our options are: 1. Apply a SELinux check when it is set to see if the caller is allowed to own the bus based on MAC labels and policy, and if not, refuse to create the connection (that's what checking the owner permission was doing). 2. Separately apply MAC checks over each of those abilities (fake creds, override policy, create an activator, monitor, or policy holder, etc) when there is an attempt to exercise them (not all during connection creation), and selectively deny that ability. More invasive, more potential for breakage for applications that don't expect failure if they could create the connection in the first place. 3. Treat faking of DAC credentials and skipping of kdbus policy checking as not of interest to MAC, leaving it only controlled by the existing uid match or CAP_IPC_OWNER check. Simple, but seems to lose some of the potential benefit of using SELinux for confining processes using kdbus. privileged actually seems less interesting than owner these days, although I haven't done a thorough analysis. IIUC, creating a monitor or policy holder connection has bus-wide implications and we ought to control it so we can limit it to specific processes, not just all uid-0 processes for the system bus and not just all uid-<user> processes for the per-user bus. I'm not actually clear on the implications of activator connections or why they are limited in the same way. If we keep them both, then they need separate classes or separate permissions; I can't think of another case where we reuse the same class and permission for two different objects. Not clear that this kind of pairwise checking will work well. For example, I should be able to own any name I like on my own bus, but not on the system bus. Perhaps not. Well, here we again have the issue that we should be able to see all names on our own bus, but not necessarily on the system bus.