Initial draft of privilege escalation policy

Christopher Beland beland at alum.mit.edu
Sun Jan 24 01:54:51 UTC 2010


Regarding system logs, maybe it would be easier to say that users with
insufficient authorization should not be allowed to erase or overwrite
information already in the system logs, though they may append data.
This hurts my brain a bit less, because it covers both the existing
system logger and any new privileged programs which might be created to
mediate log-writing.

If the universal rule is "any given process cannot write to logs, but it
can cause another process to logs" then a literal reading implies that
no logs can ever be written.


There are a few other scenarios that I don't think are addressed by the
second draft, in which I could see privilege escalation being used as an
attack vector:

* Talking to another user's X server and causing unauthorized windows to
be displayed to that user, viewing that user's windows, or capturing the
keyboard or mouse inputs of that user.
* Talking to another user's sound server or the sound hardware, and
listening to another user's audio output or input, causing unauthorized
sounds to be played.
* Accessing a webcam or microphone remotely and unexpectedly viewing or
listening to a local user.
* Monitoring another user's network traffic or injecting unauthorized
content

It's not necessary to specify a specific policy about who should "own"
these various I/O devices, but I think it may be necessary to specify
that a privileged process should not allow an unprivileged user to
circumvent whatever policy the system administrator has configured.

-B.



More information about the test mailing list