Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I will need to give root password to my server to someone who will help me setup my mailserver. Now, since this will be a freelancer I'm kind of worried he may do some damage, so I'm wondering if there is a possibility where I can see "live" (Ill be connected at the same time he will be) which commands he is issuing and if he runs a file copying (my main concern is so that someone doesn't copy the files located in my /html folder) that I will be able to cut him off and change the pass immediately.

edit: The way I did it in the end was I've setuped the teamviewer session and prepared the terminal (loged in as root) before he conected. Then, I monitored all the commans he issued. This way I didn't have to give him the root pass.

share|improve this question
    
Apart from the root password issue why not consider running a shared GNU screen session? –  pfo Apr 25 '12 at 8:39
    
I suggest in future you either learn to do the job yourself or only employ people you trust. Also ensure you have a tested backup before any work starts. –  John Gardeniers Apr 30 '12 at 10:01

3 Answers 3

up vote 3 down vote accepted

I think it will be a bad idea to give him root password if you don't trust him. When he gets the password he can do whatever he wants.

What if he just changed root password before you can even notice that.

To answer your question about monitoring the user activity, you can try whowatch. It can show you the logged in users and the processes they are running. However, you may not be able to notice a quick commands like doing ls in a small directory.

share|improve this answer
    
ouch!, good point. Ok, so I do have an additional user which is in my sudoers file and has all permissions - then imo would be the best to give him that user. But still, the monitoring question remains. –  Nikola Apr 25 '12 at 7:57
2  
@Nikola: The same idea applies to a normal use with sudo privilege. It will be better if you can create a limited user for him. You can grant him sudo privilege for specific commands only. –  Khaled Apr 25 '12 at 7:59

As @Khaled said, giving root away is impossible to track if the user is out-and-out hostile but for an identified user, of unknown quantity, its better to treat them like a naughty child. There are some steps, below becoming progressively more paranoid with each one... ;-)

1) Inform them that you are watching.

Set a suitable login policy message in /etc/motd for example;

------------------------------------------------------------------------

This is a private system; explicit authorization from the system owner
is required for access or use. Unauthorized access or use may result
in severe civil and/or criminal liability, including without limitation under 18 USC Sections 1030 et seq. All rights whatsoever are reserved. All activity is monitored and logged.

------------------------------------------------------------------------

2) Make sure that they are aware that there are rules.

Use sudo rather than root to provide administrator privileges.

A full sudo user has the same permissions as root, and hence can cover their tracks. But it is difficult, and would require a sophisticated used to erase their deeds, and erase the entries from the /var/log/auth.log

3) Have records that cannot be tampered with.

Use centralized logging and ship instance logs for /var/log/auth.log and for /var/log/messages kernel messages.

A centralized log server cannot be tampered with by the remote root user, unlike the local syslog, and the kernel and its modules. rsyslog, syslog-ng, logstash and other provide centralized logging solutions

4) Know what has been changed, by whom, when and for what purpose.

audit local activity using auditd and a basic ruleset. Or deploy AIDE or some file checksumming database.

auditd is a system daemon that records system events to a log-file,

There are a bunch of tutorials here... http://doc.opensuse.org/products/draft/SLES/SLES-security_sd_draft/cha.audit.comp.html http://doc.opensuse.org/products/draft/SLES/SLES-security_sd_draft/cha.audit.setup.html http://is.gd/34J33G http://www.ibm.com/developerworks/linux/library/l-security-audit/index.html

share|improve this answer

If you can't trust him to behave appropriately, you shouldn't give him access at all.

A shared screen session as suggested above is a good idea, or giving him only a restricted set of sudo commands.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.