On Mon, Jun 10, 2019 at 12:34 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > >>> I think you really need to give an example of a coherent policy that > >>> needs this. > >> I keep telling you, and you keep ignoring what I say. > >> > >>> As it stands, your analogy seems confusing. > >> It's pretty simple. I have given both the abstract > >> and examples. > > You gave the /dev/null example, which is inapplicable to this patchset. > > That addressed an explicit objection, and pointed out > an exception to a generality you had asserted, which was > not true. It's also a red herring regarding the current > discussion. This argument is pointless. Please humor me and just give me an example. If you think you have already done so, feel free to repeat yourself. If you have no example, then please just say so. > > >>> If someone > >>> changes the system clock, we don't restrict who is allowed to be > >>> notified (via, for example, TFD_TIMER_CANCEL_ON_SET) that the clock > >>> was changed based on who changed the clock. > >> That's right. The system clock is not an object that > >> unprivileged processes can modify. In fact, it is not > >> an object at all. If you care to look, you will see that > >> Smack does nothing with the clock. > > And this is different from the mount tree how? > > The mount tree can be modified by unprivileged users. > If nothing that unprivileged users can do to the mount > tree can trigger a notification you are correct, the > mount tree is very like the system clock. Is that the > case? The mount tree can't be modified by unprivileged users, unless a privileged user very carefully configured it as such. An unprivileged user can create a new userns and a new mount ns, but then they're modifying a whole different mount tree. > > >>> Similarly, if someone > >>> tries to receive a packet on a socket, we check whether they have the > >>> right to receive on that socket (from the endpoint in question) and, > >>> if the sender is local, whether the sender can send to that socket. > >>> We do not check whether the sender can send to the receiver. > >> Bzzzt! Smack sure does. > > This seems dubious. I’m still trying to get you to explain to a non-Smack person why this makes sense. > > Process A sends a packet to process B. > If A has access to TopSecret data and B is not > allowed to see TopSecret data, the delivery should > be prevented. Is that nonsensical? It makes sense. As I see it, the way that a sensible policy should do this is by making sure that there are no sockets, pipes, etc that Process A can write and that Process B can read. If you really want to prevent a malicious process with TopSecret data from sending it to a different process, then you can't use Linux on x86 or ARM. Maybe that will be fixed some day, but you're going to need to use an extremely tight sandbox to make this work. > > >>> The signal example is inapplicable. > >> From a modeling viewpoint the actions are identical. > > This seems incorrect to me > > What would be correct then? Some convoluted combination > of system entities that aren't owned or controlled by > any mechanism? > POSIX signal restrictions aren't there to prevent two processes from communicating. They're there to prevent the sender from manipulating or crashing the receiver without appropriate privilege. > > and, I think, to most everyone else reading this. > > That's quite the assertion. You may even be correct. > > > Can you explain? > > > > In SELinux-ese, when you write to a file, the subject is the writer and the object is the file. When you send a signal to a process, the object is the target process. > > YES!!!!!!!!!!!! > > And when a process triggers a notification it is the subject > and the watching process is the object! > > Subject == active entity > Object == passive entity > > Triggering an event is, like calling kill(), an action! > And here is where I disagree with your interpretation. Triggering an event is a side effect of writing to the file. There are *two* security relevant actions, not one, and they are: First, the write: Subject == the writer Action == write Object == the file Then the event, which could be modeled in a couple of ways: Subject == the file Action == notify Object == the recipient or Subject == the recipient Action == watch Object == the file By conflating these two actions into one, you've made the modeling very hard, and you start running into all these nasty questions like "who actually closed this open file"
