On Thu, Jun 6, 2019 at 11:56 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > > On 6/6/2019 10:16 AM, Stephen Smalley wrote: > > On 6/6/19 12:43 PM, Casey Schaufler wrote: > >> ... > >> I don't agree. That is, I don't believe it is sufficient. > >> There is no guarantee that being able to set a watch on an > >> object implies that every process that can trigger the event > >> can send it to you. > >> > >> Watcher has Smack label W > >> Triggerer has Smack label T > >> Watched object has Smack label O > >> > >> Relevant Smack rules are > >> > >> W O rw > >> T O rw > >> > >> The watcher will be able to set the watch, > >> the triggerer will be able to trigger the event, > >> but there is nothing that would allow the watcher > >> to receive the event. This is not a case of watcher > >> reading the watched object, as the event is delivered > >> without any action by watcher. > > > > You are allowing arbitrary information flow between T and W above. Who cares about notifications? > > I do. If Watched object is /dev/null no data flow is possible. > There are many objects on a modern Linux system for which this > is true. Even if it's "just a file" the existence of one path > for data to flow does not justify ignoring the rules for other > data paths. Aha! Even ignoring security, writes to things like /dev/null should probably not trigger notifications to people who are watching /dev/null. (There are probably lots of things like this: /dev/zero, /dev/urandom, etc.) David, are there any notification types that have this issue in your patchset? If so, is there a straightforward way to fix it? Generically, it seems like maybe writes to device nodes shouldn't trigger notifications since, despite the fact that different openers of a device node share an inode, there isn't necessarily any connection between them. Casey, if this is fixed in general, do you have another case where the right to write and the right to read do not imply the right to communicate? > An analogy is that two processes with different UIDs can open a file, > but still can't signal each other. What do you mean "signal"? If two processes with different UIDs can open the same file for read and write, then they can communicate with each other in many ways. For example, one can write to the file and the other can read it. One can take locks and the other can read the lock state. They can both map it and use any number of memory access side channels to communicate. But, of course, they can't send each other signals with kill(). If, however, one of these processes is using some fancy mechanism (inotify, dnotify, kqueue, fanotify, whatever) to watch the file, and the other one writes it, then it seems inconsistent to lie to the watching process and say that the file wasn't written because some security policy has decided to allow the write, allow the read, but suppress this particular notification. Hence my request for a real example: when would it make sense to do this?
