in reply to Re^3: Secure Webmin
in thread Secure Webmin
Yes! The Webmin daemon should not care if the commands come from the command line or a web ui or a GUI or whatever. If a user knows JSON, they should be able to connect via telnet over SSL and run webmin commands.
Important conceptual difference: In my system there is no difference between Usermin and Webmin. All users authenticate and different users are allowed to run difference commands. For instance, anyone on the IT staff can change anyone elses quota for them, but normal users can only change their own quota.
The conversation between the client (web ui) and the privileged daemon takes place over one TCP connection and contains only one transmission and one response. Every request contains the username and password. There is no concept of sessions in the privileged daemon.
Here's how authentication/authorization works on my system. Lets say my users are listed in LDAP. I want to let any user check their own quota. Bob logs into the web UI. His username and password are stored in plain text in the Catalyst session stuff somewhere. (This may be horribly horribly wrong.) The Catalyst app uses an LDAP module to check if Bob is really Bob. Bob is now logged into the web ui. Bob clicks the 'check my quota' link. Because Bob does not need to be a special user to check his own quota, no further authz checks are performed. The web ui forms a YAML request containing his username and password from the session data and the request for Bob's quota, and sends that to the privileged daemon. The privileged daemon gets this information and uses an LDAP module to check if Bob really is Bob. Since Bob needs no special privileges to check his own quota, he is considered authorized ( a check against a role database would be performed if he was trying to check someone else's quota). Then the privileged daemon performs the actual check and returns the result.
Here's a bit of security philosophy I picked up as an OpenBSD admin: Don't think about exploits, think about better code. The reason is, you don't know what new exploits are going to look like. You shouldn't need to know a thing about attacking servers to write secure code.
|
|---|