Jordan Brown wrote: > For the purposes of this case I don't care one way or the other - Darren > asked for it, Gordon said OK. However, I think there are interesting > philosophical questions, so I'm continuing the discussion in private. > If anybody else is interested in joining in, just ask (privately). > > Darren J Moffat wrote: >> Jordan Brown wrote: >>> For devices, I was under the impression that it was preferable to >>> rely on file system permissions rather than having the driver do its >>> own access control checks. Should that precedent apply here? >> >> Depends, but this isn't a driver it is a door server. >> >> IMO door servers need to be as robust as possible - particularly if >> they are running with any privilege but even if they are running as a >> "normal" user. Not only should they check who the peer caller is but >> they also need to be very very careful about how they parse the input >> coming over the door. See the (unfortunately closed) source for kcfd >> as an example.
In this case given the daemon is running as a normal user (but I assume it originally started with privilege so has SNOCD set right?) the door server should check that its euid matches that of the caller, or the caller's euid == 0 and has all privs (or the kernel will use a cred_t with euid == the user's). Additional protection that we are really being called by who we expect it to be called by - which BTW isn't actually clear from the case materials. -- Darren J Moffat
