On 6/5/2019 1:41 AM, David Howells wrote: > Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > >> I will try to explain the problem once again. If process A >> sends a signal (writes information) to process B the kernel >> checks that either process A has the same UID as process B >> or that process A has privilege to override that policy. >> Process B is passive in this access control decision, while >> process A is active. In the event delivery case, process A >> does something (e.g. modifies a keyring) that generates an >> event, which is then sent to process B's event buffer. > I think this might be the core sticking point here. It looks like two > different situations: > > (1) A explicitly sends event to B (eg. signalling, sendmsg, etc.) > > (2) A implicitly and unknowingly sends event to B as a side effect of some > other action (eg. B has a watch for the event A did). > > The LSM treats them as the same: that is B must have MAC authorisation to send > a message to A. YES! Threat is about what you can do, not what you intend to do. And it would be really great if you put some thought into what a rational model would be for UID based controls, too. > But there are problems with not sending the event: > > (1) B's internal state is then corrupt (or, at least, unknowingly invalid). Then B is a badly written program. > (2) B can potentially figure out that the event happened by other means. Then why does it need the event mechanism in the first place? > I've implemented four event sources so far: > > (1) Keys/keyrings. You can only get events on a key you have View permission > on and the other process has to have write access to it, so I think this > is good enough. Sounds fine. > (2) Block layer. Currently this will only get you hardware error events, > which is probably safe. I'm not sure you can manipulate those without > permission to directly access the device files. There's an argument to be made that this should require CAP_SYS_ADMIN, or that an LSM like SELinux might include hardware error events in policy, but generally I agree that system generated events like this are both harmless and pointless for the general public to watch. > (3) Superblock. This is trickier since it can see events that can be > manufactured (R/W <-> R/O remounting, EDQUOT) as well as events that > can't without hardware control (EIO, network link loss, RF kill). The events generated by processes (the 1st set) need controls like keys. The events generated by the system (the 2nd set) may need controls like the block layer. > (4) Mount topology. This is the trickiest since it allows you to see events > beyond the point at which you placed your watch (in essence, you place a > subtree watch). Like keys. > The question is what permission checking should I do? Ideally, I'd > emulate a pathwalk between the watchpoint and the eventing object to see > if the owner of the watchpoint could reach it. That will depend, as I've been saying, on what causes the event to be generated. If it's from a process, the question is "can the active process, the one that generated the event, write to the passive, watching process?" If it's the system on a hardware event, you may want the watcher to have CAP_SYS_ADMIN. > I'd need to do a reverse walk, calling inode_permission(MAY_NOT_BLOCK) > for each directory between the eventing object and the watchpoint to see > if one rejects it - but some filesystems have a permission check that > can't be called in this state. This is for setting the watch, right? > It would also be necessary to do this separately for each watchpoint in > the parental chain. > > Further, each permissions check would generate an audit event and could > generate FAN_ACCESS and/or FAN_ACCESS_PERM fanotify events - which could > be a problem if fanotify is also trying to post those events to the same > watch queue. If you required that the watching process open(dir) what you want to watch you'd get this for free. Or did I miss something obvious? > David
Attachment:
signature.asc
Description: OpenPGP digital signature
