On 2/08/10 08:58 AM, Giovanni Schmid wrote:
Bayard Bell ha scritto:
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–sec
urity 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?
As for any other administrative account, having root as role is an
improvement both in term of security
(layered defense) and auditing. Anyway, if you feel uncomfortable
having this setting, you can change it
in a matter of seconds, by simply running "rolemod -K type=normal root"
I disagree that it is a layer of defense.
There are any number of login methods that have built in "do not let
root login this way" features. So now, rather than try to attack the
root account, a hacker is forced (if they weren't before) to target
another account. And once they crack that account, all they need to do
is run "pfexec" to gain privilege. Unlike su, there is no second
password required to run pfexec in the current installation. In effect,
every account that can run pfexec and assume all of those privileges
without a password is now a root account yet there is no restriction on
where they can be logged into from.
From a security perspective, I'm wondering if in the pursuit of making
it easier to audit root that we've made it easier to access root.
Personally, I think I'd be willing to trade the restrictions and extra
security checks that go with supporting root as an account for the extra
audit capability that comes from root as a role.
Just having root as a role does not tell you "whodunnit", you need to
know what command was run when and by whom.
Many years ago I actually used the system auditing features of Solaris
for a short time in a commercial environment for a brief time. There was
just too much data generated and the work required to make something
meaningful from it too great to actually defend leaving the feature
enabled, thus for me there is currently no reason to be pro-audit.
I've also used process accounting in multiuser systems and have
successfully traced down "whodunnit" with traditional security due to
commands and tty - no audit features were present or required. It did,
however, require the subject to be ignorant about process accounting.
I'm not trying to say that audit is pointless but that for most people
it is not currently useful and thus there is little gained by enforcing
root as a role to add value to forensics through audit. If better tools
become available then I will re-evaluate the equation.
Darren
_______________________________________________
security-discuss mailing list
[email protected]
