Inter-process privilege verification
Inter-process privilege verification
- Subject: Inter-process privilege verification
- From: Wade Tregaskis <email@hidden>
- Date: Thu, 11 Mar 2004 23:11:22 +1100
This isn't entirely a Cocoa issue, but it's involved with, so I hope
it's not completely off topic. It's a bit long, and I apologise for
that, but my minds too muddled up with it all at the moment to get a
concise description down on paper.
I'm trying to setup a root daemon to serve a simple database. It will
have several users, who will just read data from it - that's easy
enough, the data is readable to anyone and everyone. The main problem
is that I want to have a GUI program be able to effect change upon it,
in various forms (whether from a single users privileges, or as root).
That's about my problem; I don't know really where to go from here.
There doesn't seem to be any way to check the privileges of another
process you're talking to via any IPC mechanism (I'll probably use
Distributed Objects, FWIW, whether via named sockets or mach ports I
haven't decided). So, I was thinking I could have the GUI app write a
change file to disk, which it could then instruct the DB manager to
read in. The DB manager could then check the permissions on the file
to determine what changes may be applied (based on the owner & who has
write access to it [i.e. must only be said owner]), and return an
appropriate result to the GUI program. Sound good so far? I'm a bit
worried about the possible use of some particular chown/chmod sequence
to edit the file (should it be world-writeable, say due to an error)
and then chown it to root or somesuch. In my testing (on Panther) I
couldn't find any way to 'break in' via this sort of method, e.g. chown
always changes the owner to the current user, presumably for just this
reason. But is it something I can rely on that only the owner, if it
has write access, can be the one that wrote to the file, assuming I
trust the writing app not just to chmod some existing file or similar?
Almost as an aside, to avoid replay attacks I was thinking the DB
daemon could supply the GUI app with some random data, which the GUI
would then include in the file. The DB daemon would only accept the
use of that data 'key' once, whether successful or not. It could
optionally delete the file afterwards, to further avoid any possible
issues.
That seems like it would work, to me, but I've never actually done
something like this before, and there seem like a lot of angles into
the system. I would think there must be some standard way for doing
this sort of thing, but googling hasn't brought anything useful up -
indeed, any search with "privilege" in it returns as the first few
hundred results pages regarding privilege escalation bugs, mostly in
Windows. Darkly humorous, but not helpful. :)
Of secondary but still significant importance, it's essential that
users of the DB be able to verify that the DB daemon is running with
root privileges, to ensure they don't get handed data from just an old
program (one user in particular will be root itself, and uses data from
the database for configuration and so forth). I was thinking a similar
mechanism could work - users hand the DB daemon some random data, which
the daemon then includes in the output file, which the user can then
verify is writeable only by root. But the problem now is performance -
while writing to the DB may occur user-frequently (e.g. at most every
few seconds, more likely hours), reading may occur program-frequently;
hundreds of times a second. Jumping through all these loops involving
the file system could potentially be very slow, if the FS is already in
heavy use (as it may well be, as a result of one or more of my
programs).
Also, just in case anyone's wondering, it's not possible to just write
to the DB via a setuid or otherwise privileged app, because:
a) I want the same sort of reliability and linearity guarantees you get
with a real DB
b) I don't particularly want to have to read/write a potentially large
DB file (several megabytes; nothing tremendous) all the time
c) I want non-root users to be able to effect changes on the file.
i.e. the file can contain per-user settings, which that user can
obviously edit. They couldn't, of course, edit other user's settings
or root/global ones.
I could use multiple DB's, one global root one and one for each user,
which would get around a lot of these issues, but I'm trying to avoid
that if possible - the DB daemon may well perform a bit of processing
of the data, and having it spread all over the place will just make
that more difficult to do.
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.