The fundamental problem that created su

June 8, 2014

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.)

Comments on this page:

maybe you are positing that "su" and something like RBAC are in a zero-sums game?

The fact of it is, that su is useful to complement RBAC. Roles being created and assigned, there would still be an "su" to be able to use such roles or gradated user ids (with limited powers as opposed to the whole system with root).

By cks at 2014-06-09 00:33:50:

I am positing that RBAC mostly solves a different problem than su does. This is almost by definition; RBAC grants limited power (possibly with the ability to turn it off), su to root grants all power. If you have all power you can use limited subsets of that power under some circumstances (provided that this is feasible to use and to keep track of), but you remain with the need to obtain unlimited power some of the time.

Also I believe that the origins of su and RBAC are different. RBAC was not created as a way of making unlimited power safer; it was created to meet a need for limited power, generally delegated to people who do not have all power.

By opk at 2014-06-10 13:07:18:

I've rarely ever seen people bother to enable RBAC. It adds a lot of complexity for gains that are hard to justify to your boss. One other somewhat hidden system for selective permissions is dbus activation.

Written on 08 June 2014.
« Some ways to do sleazy duck typing in Go (from a Python perspective)
A challenge in new languages: learning to design good APIs »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jun 8 01:27:43 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.