How do you configure RHEL 4.0 to allow the "root" account to set a screensaver?

Hello.  We are building a lab that is heavy with Red Hat Enterprise Linux 4.0 (Update 2).  As part of our security hardening, we need to be able to allow the local adminstrator accounts (root) to set a screensaver.  RHEL 4.0 by default does not allow this but we know there is a workaround solution (other organizations have successfully done this but consider their techniques to be proprietary).  We haven't stumbled on to the magic formula yet.

Does anyone know how to allow the root account to set screensavers?
Who is Participating?
nociSoftware EngineerCommented:
Think about it a little...

Why would you like a screen save for root....
- you shouldn't work under the root account (regularly)
  use sudo for the tasks where root access IS required.
- Why waste resources of servers on showing some pretty pictures etc.
  (other than the BLACK-screen screen saver that is) while not using the

So there is a reason for not having a screensaver by default.
that said..

you can run a screen saver by: xscreensaver
and it will tell you this:

xscreensaver: initial effective uid/gid was root/root (0/0)
xscreensaver: running as nobody/nobody (65534/65534)

xscreensaver: This is probably because you're logging in as root.  You
              shouldn't log in as root: you should log in as a normal user,
              and then `su' as needed.  If you insist on logging in as
              root, you will have to turn off X's security features before
              xscreensaver will work.

              Please read the manual and FAQ for more information:


I hope this helps.
L3MSAuthor Commented:

Thank you for your response.  I guess I should answer your questions as to why I need this done.

The Linux Systems I am working on are for the U.S. Government and as such, they will be part of a classified network.  Hence, they will fall under NISPOM Chapter 8 requirements for security hardening.  One of those requirements is that screensavers cannot be blank.

Since the root account cannot set a screensaver, it is conceivable that an administrator could be logged in as "root" (something we do quite a bit in order to load and maintain certain software packages) , could leave the machine and forget that they were logged in.  Without a screensaver lock, anyone could then sit down at that machine and work the system with local administrative privileges.  That is a potential security breech that is not permissable under NISPOM Chapter 8.

A better way to explain it would be a comparison to the Windows OS.  In Windows, I can go in and modify certain registry settings so that no matter who is logged on (local or domain), a locked screensaver will come up after a certain amount of idle time.  I can also set it so that the same exact screensaver comes up for everybody who uses that machine.  I would like to be able to do the same thing with my RHEL 4.0 Systems.

I am currently looking through the links you provided to see if any such procedure is possible.

nociSoftware EngineerCommented:
If you want to setup a secure environment 1st look into security enhanced version of linux (Enguarde linux, selinux kernels of RedHat etc)
From the root account there is ABSOLUTELY no guarantee about anything,
that's what the root account is built like in unix YOU CAN DO ANYTHING.

the only thing you can do is setup syslog logging to an external machine
and have that machine inaccessible by the same people that run the
other systems. Lack of certain logging means compromise, and the last logging will show when it happened.

That said there always is the problem WHO is root, was it john, joe, whoever,
C.R. Acker? So the next best thing is to firbid the use of root., Have it's password set to a Real Random String of say 20-25 characters (some unices are limited to 8),
(base64 encoding of some output of /dev/random?) and store those passwords in sealed enveloppes in a safe, (if needed to be opened by two different people present at the same time).
To handle special tasks like installing software etc. use SUDO,
where john & joe are actualy logged when the action takes place.
Also setup sudo when special privileges are needed, f.e. make a backup.
Like, the backup account IS allowed to tar the whole system with root privileges.
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

You should be using SuperUser for this.

man su
nociSoftware EngineerCommented:
For su you still need to know the password of root, with sudo you dont and you can set policies on what commands can be run under what account; possibly root,
but also f.e. restrict oracle-DBA's to use their own account and not 'oracle' and
have the export & start/stop use through sudo)
su is an alias for sudo my friend.
nociSoftware EngineerCommented:
su is quite different from sudo...

ls -l /bin/su
-rws--x--x 1 root root 24812 Oct 17 20:32 /bin/su

ls -l /usr/bin/sudo
---s--x--x 1 root root 104520 Jun 14 17:12 /usr/bin/sudo

Please compare 'man su' and 'man sudo'

with su you can become another user if you know the credentials of the other user or if you are root.

with sudo you can execute programs on behalf of the other user. And optional you need your OWN
password to do that. one of the programs that you can execute might be a shell.
In that case sudo looks like su.

So they are quite different.  
su comes from the shadow package:
sudo comes from the sudo package:

Kerem ERSOYPresidentCommented:
To make a long story shory. The screensaver used in RedHAT does not allow to be run as root. To achieve this the best idea is to set-up sudo as noci pointed and use another standard user for admininstration. In fact today most modern desktop implementations do the same and ban root from logged on to the GUI interface.

PS- NISPOM is not clear about how to logon a system but There are several references to need-to-know etc. If we interpret it in the essence as a general rule you must not use root to logon a system. Thsi will decrease the efficiency of audit trailing.

You can check ubuntu linux even grab a CD copy:

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.