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–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?
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"
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!
Are you sure ? I'm running snv_111b, and SoundJuicer is just an
executable owned by root which can be launched by everyone:
$ ls -l /usr/bin/sound-juicer
-rwxr-xr-x 1 root bin 181860 2009-05-14 17:52 /usr/bin/sound-juicer
$ pcred `pgrep sound-juicer`
1219: e/r/suid=101 e/r/sgid=10
In your observation is correct, you should file up a security bug...
Cheers, giovanni
_______________________________________________
security-discuss mailing list
[email protected]
_______________________________________________
security-discuss mailing list
[email protected]
