Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have been volunteered by my boss to be the sysadmin for our production redhat server. He asked me to tighten the security to avoid mishaps like rm -f * that occured not long ago.

Right now, we have 53 users sudo-ing into the machine and it is an audit nightmare. I am wondering if it possible to allow user access only on specific days of the week.

For example, can I have user 'Joe' allowed to login on Tuesdays and Thursdays ONLY and 'Jane' only on Sundays? Can etc/sudoers be customized to allow this?

Is there a better way instead of using sudoers?

share|improve this question
10  
I would recommend NOT reading the manual page. See xkcd #1343 –  user60684 Mar 28 at 17:57
3  
No, I am telling him to not read the manual because it is impossible to read IMHO. The OP would probably find an answer in the man page if it was easier to read. –  user60684 Mar 28 at 18:08
8  
You can do this, but keep in mind that users can just give themselves back all-the-time sudo access on whatever day they have root. –  kundor Mar 28 at 23:54
2  
@Mark0978 if you knew the name of the company, you would probably die laughing your head off. It is a disgrace that it is permitted...on a production server. –  Chris Mar 29 at 15:35
3  
This seems kind of silly. It just means Bill will have to wait for his Wednesday morning time slot to run rm -rf /. –  Michael Hampton Mar 30 at 3:39

4 Answers 4

up vote 19 down vote accepted

sudo does its authentication through PAM, like pretty much everything else on a Linux box.

So you should be able to use pam_time.so to do this.

By default on Debian at least, that module isn't enabled. You need to add a line that looks like this:

account    requisite  pam_time.so

to either /etc/pam.d/sudo to enable for only sudo or to /etc/pam.d/common-account (after the pam-auth-update block) to enable for all programs on the system.

Then edit /etc/security/time.conf to set your restrictions. The service name should be sudo. For example, to allow Fred to use sudo only between 3pm and 5pm on Friday:

sudo;*;fred;Fr1500-1700

(NOTE: I have not tested this.)

edit: To be clear, I agree with the other answer and the various commenters, you appear to have too many people running too many commands as root, and you really need to fix that. And of course if they can become root, they can edit the pam config...

share|improve this answer
    
PAM seems complex to implement but also permits tighter control on who does what and when. Accepted and voted up. Thank you. –  Chris Mar 29 at 15:36
2  
I don't think encouraging him is the right answer, IMAO the correct answer to this question is "RUN FOR THE HILLS!!!!1!1!!1!1" –  Lohoris Mar 30 at 0:04

I would question why 53 users need sudo to do their day to day work -- for most users (even developers), sudo should be a rare exception, not such a routine thing that someone would casually run a sudo rm -rf * command.

Can you use group permissions (or even more advanced ACL's) to give people access to the files they need to get their work done, perhaps with some setuid or sudo'ed scripts or binaries to let them do things like restart services? (note that it's hard to write a secure setuid/sudo script, so it's more to keep honest people honest).

Even if you can restrict people to one day a week of sudo access, that's still 53 people with sudo access in a week's time, so it doesn't really help with your core problem.

For that matter, I'd question whether that many users need access to a production server at all -- can you ship logs or whatever data/files they need to a non-production machine?

share|improve this answer
    
Or can you publish some kind of access to the log files they might need, a chroot jailed sftp kind of setup. –  Mark0978 Mar 29 at 14:43
    
@Johnny the majority of the work done on this host is creating/editing and running shell scripts. Users should not be allowed to vi/cp/mv/rm. Only cd and more. Nothing else. –  Chris Mar 29 at 15:47
    
@Johnny If I set an ACL on a directory, are the files within that directory inheriting the ACL's attributes by default? –  Chris Mar 29 at 15:53
    
@Chris Yes, if you set the Default ACL for the directory. –  Michael Hampton Mar 30 at 16:10

The simplest way would be to use to use suders.d (via inludedir) for your configuration. You could then have cron jobs that could place the rules for each user in to that directory for the times you desire.

The #includedir directive can be used in /etc/sudoers to create a sudo.d directory that you can drop sudoers rules into as part of your rules.. For example, given:

#includedir /etc/sudoers.d

sudo will read each file in /etc/sudoers.d, skipping file names that end in ‘~’ or contain a ‘.’ character to avoid causing problems with package manager or editor temporary/backup files. Files are parsed in sorted lexical order. That is, /etc/sudoers.d/01_first will be parsed before /etc/sudoers.d/10_second. Be aware that because the sorting is lexical, not numeric, /etc/sudoers.d/1_whoops would be loaded after /etc/sudoers.d/10_second. Using a consistent number of leading zeroes in the file names can be used to avoid such problems.

Note that unlike files included via #include, visudo will not edit the files in a #includedir directory unless one of them contains a syntax error. It is still possible to run visudo with the ‑f flag to edit the files directly.

/etc/sudoers.d/joe would be present when you want joe to have access and you could simply remove the file to take away access.

share|improve this answer
    
I had a problem with my user specific sudoers files: 'sudoers.user1' etc. You remark about the '~' and '.' characters solved my problem. I am so glad you did read the manual! Thank you. –  Han Aug 1 at 10:07

You could add a crontab to put a users in a sudo group, and then a second crontab to take that user out.

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.