Summary: "Restricted Root"

Sorry the summary is late, but I ended up handling other things and managed to 
put this off for a  few days (didn't think I would be able to)

The replies follow, but this is a summary:
1) Bad idea, don't do it.
2) Sudo
3) Bad idea, don't do it.
4) BSM/C2
5) Bad idea, don't do it.
6) Compile up a new shell
7) Bad idea, don't do it.
8) Use the history of the shell.
9) Bad idea, don't do it.


In my case, since I have no right to force anything upon the people in 
question, most of the following answers can't be used (much as I'd love them 
to be).
In fact, someone else is handling this now - it is being made clear that we 
cannot provide ANY form of uptime statements/etc, as well as every other form 
of support being on a 'best endeavour' on this machine - but since it has gone 
quite a long way up the management scale (we pushed back as hard as we could) 
its going through regardless of our objections.

In order of personal preference I think I'd go for the options:
1) sudo
2) recompiled shell, with an understanding that if they run another shell, I 
kill them, and they lose access, and the machine is down for 24 hours while I 
restore from a backup.
3) BSM/C2 logging.

My main objection to the BSM/C2 is that I don't like the idea of (from the 
skim reading I did before someone else took over) every system call passing 
through the logging procedure. *shrug*

Thanks to all,

Graham


Replies:


-----
If they have unrestricted root, i.e., a shell with id 0, they can undo
and hide anything you would setup. If they only need to perform some
actions, you could investigate sudo.
-----
You could try "BSM/C2" auditing; make sure that users must "su" to root
and cannot login directly as root.
-----
If you use a shell with command history you can track their use.
Foe example create another account with uid and gid 0, and give it ksh and
its own home directory.
-----
I'd be inclined to force this.
Or, have a policy of "if you have r00t, then you are 100% responsible
for that machine." and if they insist, you give them r00t for that machine
and hands-off.
I found that the first time they screw up, they will change their demands
and beg you to take it off them. I've done this three times to three different
groups, worked every time. Well, the third group heard about what happened to
the second group and suddenly changed their mind.
-----
This also lets you set up a special shell without risking loss of the root 
account
thru a typo.  Give prr its own home directory and in there put a .profile
with
    /usr/bin/script -a /wherever/logstuff
and you'll have a session log.
-----
Check out PowerBroker by Symark software. We use it for a similar purpose to
what you require. It unfortunately costs cash put it is very good.
-----
If you're giving root access out, forget logging. You've got no control over
the system, and the logs can't be guaranteed to be accurate.
Users don't need root privileges. If they run into problems as users, it's
usually because the system isn't configured appropriately.
This is ridiculous. If you have no control over root access, your whole
network is compromised. If you can't sell this fundamental idea to your
management, find another job. They obviously don't know what they're doing.
Sorry I can't provide a panacea. I've been through this same argument a few
times. I feel your pain!
-----
What you want is a SHELL that logs all the commands somewhere ... right ?
Well ... I thing getting bash source code and slightly modifying it will do
the job
-----
This may not be it either, but have you considered giving each user
an "r" login.  These are generally named with an r prepended to their
user name (rdebbie, rrauxon, etc) but with UID of 0.  Since many things
log by username (and not just UID), this gives more logging of activities
than just giving everyone root access.
Alternately, users can use sudo to exec a shell as root, which gives
them full root access but logs the time that they did is, so that it's
somewhat possible to correlate who did what (especially if you have
both tty # and when the user invoked the root shell).  It's harder to
figure out when two or more users invoke a root shell at the same time.
-----
What kind of servers are these?  Production app servers or development 
servers?
In either case, if they won't listen to reason (and there are alot of reasons 
on
why this shouldn't be done) then just give it to 'em.  Forget logging or
restricting or anything else.  And make sure that everyone understands the 
time to
restore these particular machines.
You could use flash to create a quick image of these machines every night so a
restore could be done very quickly, but that's another topic...
And if you want to cover your butt's, you guys use sudo yourselves so all your
commands are logged...these logs can be sent to an nfs server where the 
liberals
(I mean users..) don't have root access.
-----
for auditing use the audit system:
/ect/security/*
see this doc: http://www.sun.com/solutions/blueprints/0201/audit_config.pdf
If you give somebody root access, he can change everything in the system
(also your RBAC configuration). You will not have any control, because he
could just detect, manipulate or remove all your logging procedures if they
are running on the same system. He could also detect any network traffic, if
some processes send data to another system. And he could install root kits
and other OS manipulation tools.
The way to watch a root user is to do it from an external system. So the
root user of this logged system has no access to your logging processes and
could possible not detect them.
I don't know, how your external root users connect to your system, but if
they use an unencrypted telnet or rlogin connection, you can simply snoop
the network from any system in the networks between both hosts to see every
keystroke they do.
If they use an encrypted connection (e.g. ssh) then it is more complicated,
because ssh is using an end-to-end encryption. Try to install a connection
proxy also called "man-in-the middle" system (see port forwarding in ssh)
if you have an intelligent router, you could also configure it, that it
sends only the ssh connections (port 22) to the proxy and all other
connections directly to the target.
see also http://project.honeynet.org/papers/honeynet/
-----
I have used with success the BSM of Solaris (called also c2audit):
http://docs.sun.com/?p=/doc/806-1789
Please keep in mind that BSM logs can become very large and detailed, and
if I remind correctly the default option is to lock the system if the space
of the partition for the logs become full (concept: security is most
important than availability).
I think the only big true problem for you about c2audit is the unability to
send the logs to a remote server in realtime (you can do it only with
NFS/CacheFS, but a malicious root can delete or modify them).
-----
Why don't you use the BSM audit system that comes with Solaris?
Certainly they could tamper with the audit logs if they are root.
I don't understand why they have to be "root" when there are numerous
ways to give them whatever "access" they need.
I've seen this question posted to lists before. I'm baffled by it.
People must have some seriously clueless managers. Good luck!
-----
Have you available pacct file.
Execute /etc/rc2.d/acct start
With lastcomm command you can see all command the people are running in your 
machine.
-----
you could use syslog to log to another host and don't
give them access to the other host, or turn on full
auditing in the bm_conv module.
-----
Download bash source code. Find spot right before command is
executed. Insert 3 lines of code. What are these 3 lines?
A call to syslog! (openlog, syslog, closelog). 4 lines if
you count #include <syslog.h>. Compile. Drop into place.
Set your syslog.conf's to forward/record the specified priority.
Create a uid 0 user, give him the 'special' shell.
Only caveats are that it doesn't work if the user executes
another shell.
Maybe that will be sufficient to fulfill the unreasonable
demands? sudo is the better option, and you should really
push *hard* for it.



-- 
Whomever goes to fight monsters should take care not to become a monster
himself. And when you stare too long into the abyss, the abyss stares back
into you. 
                                                      -Frederick Nietzsche
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers