Wandering Thoughts archives

2014-06-08

The fundamental problem that created su

There is a fundamental problem that su, sudo, and many other tools are used to try to solve. Actually there are two problems, but su only addresses the one so let's start with it.

The first problem is that you have the right to exercise all power but you do not normally want to exercise that power. Most of the time you want to have no power and perhaps some of the time you might like to have some focused power; this is primarily to limit the scope of accidents and mistakes. If you are duly authorized to do everything on a Unix system, well, perhaps you could just give your account a UID of 0 but almost everyone agrees that that would be a terrible idea. It is much safer not to have all power almost all of the time and to exercise that power for as short as possible a time and in as limited as possible a way.

(Well, really it is 'feasible' instead of 'possible'. There is a balance of tedium between free exercise of power and significant amounts of work.)

Or in short: su is there to limit a sysadmin's power, not increase it. Su is there to let you do things without the powers of root. Because su can give you power temporarily, you do not need that power permanently.

(I suppose technically you could say that su is there to increase auditability, since you can su to root and thereby leave a trace of who you used to be instead of having to log in as root in some way.)

The other problem is that you have the rights to some powers but not other powers and you must somehow be granted selective access to only those powers you have a right to. This problem is solved by setuid on selected programs, sudo in various forms of usage, and with things like RBAC. Su does not solve it directly.

These two problems are almost completely orthogonal. A solution for access to limited powers for people authorized for them does not really help people who have the right to all power but do not want any power most of the time. Perhaps in the right situation it can make their life somewhat safer if people (or scripts) diligently remember what operation needs what limited power and that limited power can be kept turned off most of the time.

(And a solution to access to limited powers does not necessarily mean that those limited powers can be turned off when you don't want them. They may be always-on enhancements to an otherwise normal account.)

This is why RBAC or an equivalent is not a replacement for su for fully root-authorized sysadmins. In fact in some ways bare RBAC is an anti-replacement, if your ordinary account winds up with more intrinsic powers than before.

This is a generic problem for any system of enhanced powers. Unless the additional powers are harmless, the sensible default state is that you do not have the powers despite having the right to them; you want an explicit activation step for safety (and you may want this activation step to involve an additional challenge or secret for increased security). Su (and traditional UID 0 in Unix in general) is only unusual in that the powers are an all or nothing affair instead of selective.

(There are relatively few additional powers that are genuinely harmless. Powers that enable system changes are obviously dangerous but even mere information disclosure powers may give you normally private information that you don't want to know or should not know without real need.)

unix/FundamentalSuProblem written at 01:27:43; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.