I have been thinking a bit about how to implement the privilege
separation. I will try to reason abit. Feel free to comment where I go
wrong or where there are (better) alternatives.
* we want as little as possible run as root.
* the only thing that actually needs root is the persistance manager.
* separating privileges means in practice, running a separate process
* The lower privilged parts needs communicate with the privileged
process. some kind of IPC.
We could either let the privileged parts of persistance manager run as
daemon or we could fork a suid root executable on demand. (or a daemon
that is executed on demand and dies after a period of inactivity)
I think what we finally do there depends on how often we need to do
privileged calls. If very seldom, then fork/exec a suid root will work.
(suid root scares me...) This is the simplest.
Since suid root is very scary, I have been thinking of doing the
login/authentication there too. In other words you will need the
session token to do anything privileged (and i intend restrict the
paths, check write permissions on those paths etc).
So we could define what privileged function calls can be executed by
what users (or roles). Otherwise, if you gain access of the acf user
account (the http server user) you will be able to run all the
privileged calls (eg. write /root/.ssh/authorized_keys and similar).
This would defeat the entire purpose of the privilege separation.
I have done some prototyping of the suid-root, fork/exec for each
privileged call. I have a privesep lua module that will wrap some IPC
magic around your lua module.
I have also done some testing with the authentication. The idea is that
user roles are in /etc/acf/passwd (as in current acf) but password
could be shadowed in /etc/shadow.
The code is here:
You can run example.lua and testauth.lua.
Runtime dependencies are currently lua-posix and lua-json.
Received on Thu Dec 13 2012 - 22:31:44 UTC