We have a requirement for multiple root accounts on a variety of
unixes.  This is more
for logging than security.

First solution was to just make multiple root accounts but due to the
way accounting
can't differentiate between multiple accounts with UID of 0, that wont
work.

Because we want unrestricted access, we're having problems with sudo.
root users
just get a shell and that initial line is the only one logged. The
technical solution
would be to train them to 'sudo somecommand'   where somecommand or
its
parent directory is listed in sudoers but this has been found to be
too cumbersome.

Anyone have a solution?
Thanks

[ Post a follow-up to this message ]

On 22 May 2007 12:06:35 -0700 zubi <mashtin.bakir@gmail.com> wrote:
> Anyone have a solution?

keep a baseball bat in your office, go apeshit once in a while

[ Post a follow-up to this message ]

In article <1179847214.983022.196420@z24g2000prd.googlegroups.com>,
zubi <mashtin.bakir@gmail.com> wrote:

> We have a requirement for multiple root accounts on a variety of
> unixes.  This is more for logging than security.
>
> First solution was to just make multiple root accounts but due to the
> way accounting can't differentiate between multiple accounts with UID of 0
, that wont
> work.
>
> Because we want unrestricted access, we're having problems with sudo.
> root users just get a shell and that initial line is the only one logged. 
The
> technical solution would be to train them to 'sudo somecommand' where some
command or
> its parent directory is listed in sudoers but this has been found to be
> too cumbersome.
>
> Anyone have a solution?
> Thanks

Well, you've found one of the flaws of the UNIX security model--only UID
0 is root.  Whatever you name the user, UNIX scans the password file (or
whatever you use for authentication) and finds the first instance.  The
process is given that name.  Having multiple usernames with the same UID
is considered a Bad Idea(tm).

I don't think there's a technical solution for this particular problem
you've posed as far as I can see.  I'd sit down and re-think your
requirements as to _why_ you need them.  UNIX isn't really built to do
this unless you want to build and support your own kernel.  Good luck
with that.

--
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

[ Post a follow-up to this message ]

zubi  <mashtin.bakir@gmail.com> wrote:
>We have a requirement for multiple root accounts on a variety of
>unixes.  This is more for logging than security.

Logging is just an aspect of security.

>Because we want unrestricted access, we're having problems with sudo.
>root users just get a shell and that initial line is the only one logged.

Right.  Once someone has a root shell, you're done for.

>The technical solution would be to train them to 'sudo somecommand'

Training is a policy solution.  The technical solution is not to allow sudo 
to
run a shell (or any command that can spawn a shell).

There really are only two types of machines: secure systems where only truly
trusted admins have root access, and open systems where multiple people
have root access.

The normal situation is to have open machines for development and testing, a
nd
a procedure for pushing blessed software or config changes to secure
production systems.

>parent directory is listed in sudoers but this has been found to be
>too cumbersome.

It depends on your balance of security and convenience.  If you want logging
just so people can choose to log their activities, you could write a shell
that logs each command.  Anyone who wants can still avoid it, so there's no
security, but it gives you convenience.

If you want actual security of knowing who did what on a machine, you need t
o
secure the machine.
--
Mark Rafn    dagon@dagon.net    <http://www.dagon.net/>

[ Post a follow-up to this message ]

zubi schreef:
> We have a requirement for multiple root accounts on a variety of
> unixes.

No you don't ;)

> This is more for logging than security.


whatever the reason, what you need is some sort of Role Based Access
control. most *nices support this.

Paul

[ Post a follow-up to this message ]

On May 22, 7:06 pm, zubi <mashtin.ba...@gmail.com> wrote:

> Anyone have a solution?

I read 4 replies so far.
A technical solution: no. I agree with others (but Paul): once you
have root access, all bets off.

Offer the people you trust the book: Peopleware, by DeMarco & Lister,
Dorset House Publishing Co., New York (NY) 1987,
and mention the chapter: Defensive Management:

p 133-134
[...] once you have decided to go with a given group, your best
tactic
is to trust them.

p 135
The right to be right is [...] irrelevant; it's only the right to be
wrong that makes you free.

p 144
This Open Kimono attitude is the exact opposite of defensive
management. You take no step to defend yourself from the people
you've
put in positions of trust.

p 145
If you've got the wrong counsel, you're in deep bananas anyway.

p 147
There are rules and we do break them.

p 153
The group's adherence to to a corporate standard of uniformity is
almost a symbol of the manager's degree of control. [...] The more
comforting it is to the manager, the more it saps the lifeblood of
the
team.

p 155
[...] managers are usually not part of the teams they manage. Teams
are made up of peers, equals that function as equals.
[...]
The structure of a team is a network, not a hierarchy. For all the
deference paid to the concept of *leadership* (a cult word in our
industry), it just doesn't have much place here.

Marc

[ Post a follow-up to this message ]