PDA

View Full Version : Logging as root bad?


llbbl
05-22-2005, 01:57 PM
I know this is age old debate. I am not trying to start a discussion on the topic, but I wanted a collection of information that I found from around the net why logging in as root is bad practice.


1. It takes time to restore the system if compromised.
2. It's easier for a compromise to go unnoticed if the offending program has root access; if you are running any filewatcher programs like tripwire they can be replaced. (Of course, most desktop users don't bother with tripwire. I certainly don't...)
3. Does your wife / gf / children use your computer? If they are compromised, you will be too.
4. Wise desktop users will use extra user accounts to protect especially important files. Spent months creating mp3s? Create an mp3 user with read-only access to his home dir from users in group 'mp3'.
5. Stability. Buggy software that runs as root can inflict more damage. You don't just need protection from malware! This is more likely in linux anyway, since desktop system compromises are not common.

http://www.desktoplinux.com/cgi-bin/board/UltraBoard.pl?Action=PrintableTopic&Post=364&Board=linvwin&Idle=0&Sort=0&Order=Descend&Page=0&Session=

* When doing some complex command, try running it first in a non-destructive way...especially commands that use globbing: e.g., if you want to do rm foo*.bak, first do ls foo*.bak and make sure you are going to delete the files you think you are. Using echo in place of destructive commands also sometimes works.
* Provide your users with a default alias to the rm command to ask for confirmation for deletion of files.
* Only become root to do single specific tasks. If you find yourself trying to figure out how to do something, go back to a normal user shell until you are sure what needs to be done by root.
* The command path for the root user is very important. The command path (that is, the PATH environment variable) specifies the directories in which the shell searches for programs. Try to limit the command path for the root user as much as possible, and never include . (which means "the current directory") in your PATH. Additionally, never have writable directories in your search path, as this can allow attackers to modify or place new binaries in your search path, allowing them to run as root the next time you run that command.
* Never use the rlogin/rsh/rexec suite of tools (called the r-utilities) as root. They are subject to many sorts of attacks, and are downright dangerous when run as root. Never create a .rhosts file for root.
* The /etc/securetty file contains a list of terminals that root can login from. By default (on Red Hat Linux) this is set to only the local virtual consoles(vtys). Be very wary of adding anything else to this file. You should be able to login remotely as your regular user account and then su if you need to (hopefully over ssh or other encrypted channel), so there is no need to be able to login directly as root.
* Always be slow and deliberate running as root. Your actions could affect a lot of things. Think before you type!


http://www.linuxdocs.org/HOWTOs/Security-HOWTO-4.html

Some new users get into the bad habit of using root for everything. This is bad for several reasons: You can inadvertently destroy important files. You can do irreparable damage to your filesystem or wreak havoc with system processes. Also, if you are connected to a network, being logged in as root is a potential security hole for a cracker to get into your system.

If you log in as root all the time, you increase your chances of making a simple error that can cost you hours of recovery time. If you are the administrator of your system, there is a simple command called su, which enables you to assume the identity of root or any other user (if you know the password). It is much better to log in as an ordinary user, then use the su command to give yourself administrative privileges to perform a task. This is also called becoming the "superuser." If you simply type

http://www.informit.com/articles/article.asp?p=130852&seqNum=4&rl=1

..unless there is a good reason for doing so. In Linux you can create as many users as you like, all with their own home folders and permissions.

One user is special: root (also called "superuser") has the right to do anything.

Use su - to temporary become root and do the things you need, never log into your sytem as root!

Root is only for system maintainance, this is not a regular user (LWindows don't have any user management at all and uses root for everything, this is a very bad idea!).

You can execute a command as root with:

su -c 'command done as root'

Gentoo Linux: Note that on Gentoo Linux only users that are member of the wheel group are allowed to su to root.

http://linuxreviews.org/sysadmin/

spankers
05-24-2005, 11:20 AM
It's a bad practice for any operating system... Unix, Linux, BSD, Windows, VMS, HP MPE4, etc.

I wish Windows had temporary privilege elevation mechanisms like Unix does (su or sudo).

spankers
05-24-2005, 11:31 AM
It's interesting that by default the root user login is disabled in Mac OS-X.
http://developer.apple.com/qa/qa2001/qa1013.html

llbbl
05-24-2005, 05:32 PM
It's a bad practice for any operating system... Unix, Linux, BSD, Windows, VMS, HP MPE4, etc.

I wish Windows had temporary privilege elevation mechanisms like Unix does (su or sudo).

We could only wish!

cool find on the Apple link!

ECA
05-24-2005, 08:37 PM
MS does give you the option when you FIRST setup...asks for the dir to place windows...
But so many progs look ONLY in C:windows...that its a REAL pain..

dang
05-24-2005, 10:09 PM
MS does give you an option in XP. You can right-click an exe and choose "Run As". This allows you to run the exe under a particular user.

spankers
05-25-2005, 12:53 AM
MS does give you an option in XP. You can right-click an exe and choose "Run As". This allows you to run the exe under a particular user.Hmmm... I'll have to check it out next time I use a XP box. The only Windows machine I have at the house is an old PIII laptop running Win2k; everything else is running Debian.

llbbl
05-25-2005, 05:54 AM
So you think that reason so many programs won't operate if not run as root is because they are looking for shared dll's? I'm not sure what else they would be doing in the system folder. maybe MS should store references to the in a directory readable by all or something.

I know Xnview is one program that doesn't like being run as un privlaged user. What are some other examples you guys have run across?

spankers
05-25-2005, 07:13 AM
So you think that reason so many programs won't operate if not run as root is because they are looking for shared dll's? I'm not sure what else they would be doing in the system folder. maybe MS should store references to the in a directory readable by all or something.

I know Xnview is one program that doesn't like being run as un privlaged user. What are some other examples you guys have run across?As a Restricted User in Windows you should still be able to access the DLL's in the system folder (read-only). From what I've seen, most problems arise when a program launched by a Restricted User tries to write to the system registry (gak! yuck! gimme a text config file any day) or to access files the user does not have access to.

Does anyone know if Windows restricts access to TCP ports 0-1023? In Unix/Linux, access to the first 1024 ports is typically reserved for root.

dang
05-25-2005, 08:36 AM
not sure about ports, but you are right about the registry spankers. A restricted user can not install software mainly because they can't right to the registry. However, using Run As will buypass that.

ECA
05-25-2005, 10:01 AM
It would be cool if windows OS(DIR), was resticted.
And ALL new DLL's(and such) were sent to a different DIR for loading.
The reg were inviolate, with Scripts added for those progams that needed access to Startup ONLY.
It would make it so much easier to find CRAP, and virus and bots..

spankers
05-25-2005, 10:58 AM
It would be cool if windows OS(DIR), was resticted. It IS... to a Restricted User. A Restricted User in Windows cannot write to the Windows directory. This, along with not being able to write to the system registry, is why most administrators advocate not using the Administrator account as your normal login. When you run a program as Administrator, then that program has system wide permissions. This is one of the big reasons your average Windows install is not secure. Most home users run with admin privileges and because of this regularly get clobbered with viruses, worms, etc.

What makes things REALLY bad running as Admin is that an insecurity in an APPLICATION can be exploited to gain root level access to the computer. In h4x0r speak, "you are owned". If running as a Restricted User an application exploit can only effect files and directories belonging to the user.... i.e. C:\Documents And Settings\User_Name. Nothing outside the users home directory should be touched.

If most people learned NOT to use the Admin account for their normal login then 99% of the antivirus peddlers would go out of business.

spankers
05-25-2005, 11:12 AM
And ALL new DLL's(and such) were sent to a different DIR for loading. The problem with this is that DLL's (Dynamic Link Library) are often shared by different programs. Another problem with this is that the search path the OS has to use to find a library could become cumbersome (given you have a large number of directories holding libraries) and impact system performance.

In some ways, Linux uses a similar library structure. Libraries are typically in /lib, /usr/lib, and /usr/local/lib (for locally built/installed libraries). The libraries are tracked through a file named /etc/ld.so.conf and are loaded as necessary for applications that depend on them.

The neat thing about shared dynamic libraries is that you only have to have one copy of the library in memory but multiple applications can use the same copy. This really cuts down on the resources required.

ECA
05-25-2005, 02:41 PM
It IS... to a Restricted User. A Restricted User in Windows cannot write to the Windows directory. This, along with not being able to write to the system registry, is why most administrators advocate not using the Administrator account as your normal login. When you run a program as Administrator, then that program has system wide permissions. This is one of the big reasons your average Windows install is not secure. Most home users run with admin privileges and because of this regularly get clobbered with viruses, worms, etc.

What makes things REALLY bad running as Admin is that an insecurity in an APPLICATION can be exploited to gain root level access to the computer. In h4x0r speak, "you are owned". If running as a Restricted User an application exploit can only effect files and directories belonging to the user.... i.e. C:\Documents And Settings\User_Name. Nothing outside the users home directory should be touched.

If most people learned NOT to use the Admin account for their normal login then 99% of the antivirus peddlers would go out of business.


TRY to tell that to DELL, HP, and compaq...

dang
05-25-2005, 04:21 PM
thats true. a lot of oem's during their first run will setup a user account with full privileges. :(

Running as a restricter user would also stop spyware.

spankers
05-26-2005, 02:57 AM
I'd like to experiment with my Win2K laptop... as a Restricted User, deliberately try to get the laptop 'rooted', infected with spyware, etc. It has all the latest security patches in place but is not running any antivirus software as yet (I just reinstalled Win2K... don't ask!). I'll have a look at the Spyware section and if any of the goodies reported there can do any damage. Taking a look at osvdb.org and the proprietary security sites wouldn't hurt either. Also, it would be kinda cool to put the laptop on an open connection (no firewall) and observe with a sniffer, Honeynet style.
http://www.honeynet.org/

Running as a Restricted User does not make one immune to Windows kernel vulnerabilities or vulnerable services executed during boot running with Admin permissions. I believe this is how so many Windows servers running MS IIS got perforated circa 2001 (Code Blue, Nimda, etc.)

openbsd-flipp
06-06-2005, 10:01 AM
all my user acounts log into a chroot jail that allows only certin programs to run based on the purpose that i created the account. For example, my work account cannot access games, programming tools (other then emacs and gcc) , and alot of other non needed crap. The basic setup is that each user has a bin directory in their home directory that is refrenced by their profile. as an example this is the profile of my main work account

bash-3.00# cat .profile
# $OpenBSD: dot.profile,v 1.4 2004/05/10 16:04:07 peter Exp $
#
# sh/ksh initialization

PATH=/home/workmain/bin: PATH
HOME=/home/wormain
export HOME
umask 022

I have created a small script and have set this as the login shell. the contents of the script is

bash-3.00# cat restriction
chroot /home/workmain /bin/csh
bash-3.00#


all that does is to lock the user into his jail and destroys the login session upon exiting.