One basic argument for converting root to a role is that logs no longer reflect
"root did it", where that's someone logged in as root–what you are now able to
determine is whodunnit exactly using a level of privilege rather than accessing
an account, which doesn't make various auditors very happy. Now, anticipating
an objection, let me acknowledge that there are places where, having eliminated
direct login as root, you can reasonably trace the terminal from which root was
accessed to understand what account was used to get to root or use something
like sudo for command invocation. Among other limitations, this breaks down in
turn when you're trying to understand root activities in a networked
environment, so what you'd really want to see at that point is role-based
authorisations for network services rather than something reducible to uid==0.
This isn't to say that this is the only argument for doing this or even a
comprehensive treatment of this aspect, but it should indicate that there are
some compelling if involved arguments why the traditional Unix security model
is broken. What concerns me is not simply that this is broken and that, if this
is supposed to solve the problems for heterogenous distributed environments,
there needs to be some convergence to standards down the line. Given the kind
of line coming out of the GNU community on including things like strlcpy() in
glibc, I'm not sure whether people are willing to move past pissing contests
("not invented here" was how someone on the Debian list saw the essence of the
opposition from the Linux people on the glibc list) when it comes to anything
already implemented offered as a possible standard. That's not an argument
against work proceeding in Solaris, but it's a wariness as to how far some
customers may be able to go in uptake on new best practices–security can and
will be undermined in the long term if innovation is left for too long as a
matter of competitive advantage between Unix implementations rather than a core
part of the standards.
I'm not going to defend setuid root or what have you without knowing much of
the particulars, as there are solutions for facets of this set of problems. The
general problem is managing operations requiring a piece of root that are more
efficiently managed as the privileges of a piece of software rather than a set
of users. What I would say about software that still goes down that route (and
there are variably portable or non-portable alternatives for subsets of the
problem space) is that it can and should be dropping effective privileges
except around those operations that require root. This is very well-established
stuff: see Stevens and Rago, Advanced Programming in the Unix Environment, pp.
237-241 (the first edition refers to some of the calls as pending POSIX
standardisation, so let's say that the necessarily complementary privilege
revocation techniques have been around long enough that no one should be
pleading any excuses if they need root for some operations but are keeping root
to write files in a way that would violate least privilege in context, which
sounds to be the case here without sufficient information being made available
in this forum to make a definitive judgement).
security-discuss might be a better forum for further discussion, so I've CC'ed
that list.
Cheers,
Bayard
On 30 Jul 2010, at 12:59, Mike DeMarco wrote:
> Build 134:
> 1) Could anyone please explain why root has been converted to a role. I
> would venture a guess that someone somewhere believes that it is more secure
> to run root as a role. The whole "if root can not log directly into the box
> than someone can not crack the root password. Well I agree that root should
> not be allowed to login from the net but locking a root account out of
> console login relies on the user account always being valid. and how much
> harder is it to hack the user then move on to root, especially when the root
> password is the same as the users. Having root as a role is causing me many
> problems and I am wondering if others are in agreement or disagreement with
> this practice?
> 2) I have noticed that when sound-juicer is started by a non-root user the
> process runs as root and writes its files as root, WOW what a huge security
> hole this is. To have a non-privileged user able to start and control an
> application that writes files as root with root privilege to any filesystem!
_______________________________________________
security-discuss mailing list
[email protected]
