sudo and root

I have two questions:
  1. What is the maximum length of a root password in FreeBSD 9.1? (if any)
  2. If I am the only admin/root user on a server, is there any point to using sudo? I know you shouldn't use root but I currently do. I'm trying to understand the pros/cons to using my own account (that is in the wheel group) with sudo versus logging in as the root user.
I have read a few articles about sudo but it still hasn't quite "clicked" in my mind as to why I need sudo. I fully understand why servers with multiple admins need sudo for audit purposes but is there any point of me running sudo if I am the only admin of the server?

I also don't understand the difference between using a password and NOT using a password with sudo; why do you need to enter your own password each time to become root (or have root rights)? When people use sudo, do they normally just prefix all commands with sudo or is it better (or easier) to become root using sudo -s

I think I've confused myself...anyone? :\

Thanks for any advice.
 
xy16644 said:
  1. What is the maximum length of a root password in FreeBSD 9.1? (if any)
  2. If I am the only admin/root user on a server, is there any point to using sudo? I know you shouldn't use root but I currently do. I'm trying to understand the pros/cons to using my own account (that is in the wheel group) with sudo versus logging in as the root user.
I don't know about the first one. For the second one, you should have a non-root account and use sudo so you know exactly when root privileges are used. If there's a bug in a script (perhaps one you're working on,) if someone compromises your web browser, etc., it's nice to know that the consequences are limited.
xy16644 said:
I also don't understand the difference between using a password and NOT using a password with sudo; why do you need to enter your own password each time to become root (or have root rights)? When people use sudo, do they normally just prefix all commands with sudo or is it better (or easier) to become root using sudo -s
Going back to my other comment, there are various ways for someone else to obtain access to your account, e.g. you forgot to log out or lock your session, you sign in with a private key and someone obtains that key, or (again) someone compromises your browser. Requiring a password puts up a minimal barrier that blocks root access in most cases like that. You type in your own password so the root password isn't available to everyone who needs root privileges.

I actually have two accounts: one that can sudo and one that can't. I only allow the account that can sudo to log in from certain locations, and I don't store the password for that account anywhere, whereas I use a private key for the other account so I can fish:// in KDE without typing a password in every time.

Sometimes it's more convenient to run a shell as root, but normally it's only helpful if the user that can sudo can't cd into a directory that you need to do work in.

Kevin Barry
 
xy16644 said:
[*] What is the maximum length of a root password in FreeBSD 9.1? (if any)
That is a cool question, but unfortunately also one easily answered. The passwd(1) manual page tells you all about it:

Code:
The new password should be at least six characters long (which may be
overridden using the login.conf(5) ``minpasswordlen'' setting for a
user's login class) and not purely alphabetic.  Its total length must be
less than _PASSWORD_LEN (currently 128 characters).
I don't know about you, but I got immediately intrigued with a follow-up question: "What is this _PASSWORD_LEN exactly?" (though I had a suspicion due to the way of writing, even though I'm not a C programmer).

This is what programmers call a constant. This is a variable which has a pre-defined value which cannot (and should not) be changed. In several languages (my personal experiences lie in Java, C#.NET and VB.NET) it's quite common to use CAPITAL letters to make sure people realize what they're dealing with.

And as a bonus (maybe useless, but I think it's fun): this constant is set in /usr/include/pwd.h, what do you know:

Code:
smtp2:/usr/include $ grep PASSWORD_LEN pwd.h
#define _PASSWORD_LEN           128     /* max length, not counting NULL */
The reason I think this is a very cool question is because I once tried to find this same kind of information for Linux. Lets just say it's not as transparent as the examples I've shown here ;)

xy16644 said:
[*] If I am the only admin/root user on a server, is there any point to using sudo? I know you shouldn't use root but I currently do.
Now, this is another good question in my opinion, but.. Also one which doesn't have a straight answer I think, it will most likely be based on personal opinion, personal experiences as well as the situation at hand.

Yes, there is a point to sudo, just like there's a good point to not using sudo (hey; no one said this was going to be easy ;)).

From the top of my head, some advantages of using sudo:

  • You don't need to type the root password, thus if you are affected by a key logger of some sorts they'll only get your password. (critical note: then log on using your account, abuse sudo, and you're in trouble anyway).
  • You don't need to type the root password every time, sudo can remember it for an x amount of time. (critical note: and now your password becomes semi-accessible in 2 places at once).
  • sudo can also be used to automate certain commands or maintain / mimic certain environments.
  • You can also use sudo to execute programs as another account, not perse the root account.
But as I mentioned earlier there are also plenty of reasons not to use sudo. For example; by default it's set SUID and is owned by root. Thus effectively gaining root privileges the moment you start it:

Code:
[peter@ikari ~]$ ls -l `which sudo`
---s--x--x 2 root root 219272 Aug  6  2012 /usr/bin/sudo
(disclaimer: this is a Linux example, I don't use sudo on any of my FreeBSD servers, yet have reasons to assume the situation is the same).

xy16644 said:
I'm trying to understand the pros/cons to using my own account (that is in the wheel group) with sudo versus logging in as the root user.
If with "logging on as root" you meant to say "logging on as root using SSH" then you should really change your ways, but it doesn't have to be using sudo. Why not simply use su to gain root privileges?

Better yet: if you need to have the exact environment which root has, why not simply use su -?

In general: Never, ever, directly log on as root using the network.

I know you could easily use a firewall to block access to SSH and only permit it for your own IP address, but you'd still be taking a huge risk. One which you don't need to take because you'd only need 1 simple command after logging on to gain root privileges.

xy16644 said:
I fully understand why servers with multiple admins need sudo for audit purposes but is there any point of me running sudo if I am the only admin of the server?
In my personal opinion no. In fact, I would recommend not using sudo due to the SUID bit being set.

However, I know I'm repeating but I honestly consider this important to stress out: I would strongly recommend using su instead (this is assuming you're not and also currently logging on directly as root over the network).

xy16644 said:
I also don't understand the difference between using a password and NOT using a password with sudo; why do you need to enter your own password each time to become root (or have root rights)?
Simple.

At the time of writing my girlfriend sits in the living room watching.. I don't know, but for argument sake let's assume I don't trust her like I do, I'm logged on as myself on my server and sudo doesn't require passwords.

She knows some of my customer websites deal with credit card payments, got this nice PHP routine from a "friend" and I need to go to the toilet for a "long break". I need to go NOW so I don't bother to log out or lock my terminal because it's 1am and she's my girlfriend.

What's now stopping her from becoming root, add some extra stuff, remove her own tracks (remember: root is all powerful), get me an extra beer and then sit on the couch as if nothing happened?

This is merely an extra layer of protection; making sure no one can "just" gain root privileges by abusing your account.

It's the same reason why you'd need to enter your current password when using passwd before you can give a new one (but I liked my previous example a lot better :e).

xy16644 said:
When people use sudo, do they normally just prefix all commands with sudo or is it better (or easier) to become root using sudo -s
That depends. On Linux I often used sudo mc, then got to work and eventually logged off again. I also often used single commands.

It really depends on what you need to do, there is no definite answer here I think.

Hope this can give you some ideas.
 
ShelLuser said:
In my personal opinion no. In fact, I would recommend not using sudo due to the SUID bit being set.

Remember, su is also a SUID program. So I wouldn't exactly say that one is worse than the other, they both have purpose for use. I use sudo on my personal hosts as well, I think the security model works easier for me. I often use it on throwaway VMs with NOPASSWD to make my life easier for executing privileged commands.
 
I don't know where the problem with direct root-login is. I always login as the needed user (database-admin, www-admin, root, ...)

I am always using SSH keys on dedicated servers, so the only reason to use the root password is on the console. Under Linux I empty the user-passwords (Is this also possible under FreeBSD without preventing the user from logging in?). The thing with users on servers is, that I normally just use functional accounts (so a database server just got two accounts: root and dbadmin). So a database admin gets an entry in the authorized_keys file and he can work.

The problem with sudo is (beside SUID), that it is very difficult in larger environments to create a config which is "unbreakable". If you want a root-wrapper (so the user gets full root-access by using sudo) it is quite ok, but if you want to restrict users to single commands then it gets interesting (several commands have shell-exits - vi for example).

As already said it has to be decided per situation.

Markus
 
storvi_net said:
I don't know where the problem with direct root-login is. I always login as the needed user (database-admin, www-admin, root, ...)
The difference is being allowed to execute things as root vs. being required to execute things as root. If the default behavior is that commands will be executed under a non-privileged UID then you'll tend to do that, whereas if the default behavior is that commands will be executed as root, then a much larger number of commands will be executed as root.

Kevin Barry
 
Another advantage to using sudo is that it is more convenient to use it merely to run commands as root without continually needing to enter your root password every single time - without logging yourself into a root shell, or running everything as root.

Setuid isn't automatically bad if it is a legitimate program.
 
The biggest reason to use sudo (IMO) is that every command executed via sudo is logged. When you login as root, nothing that you do in that login session is logged. Even if you are the only admin on the system, having a nice, traceable log to refer to when things go sideways is very handy.

However, if all you use sudo for is to run $ sudo su -, then there's really no difference compared to just logging in as rooot. :)
 
storvi_net said:
I don't know where the problem with direct root-login is. I always login as the needed user (database-admin, www-admin, root, ...)
There is a subtle different here: we're not talking about just a direct login. We're talking about directly logging in as root over the network. So using programs like SSH and such to become root.

There's nothing wrong perse to logon as root when sitting behind the computer. Even so; the reason why it's generally preferred to use a regular user account is because you more than often don't need root privileges for common tasks. When I need to perform maintenance on MySQL I don't need the root account, all I need is a MySQL account with administrative privileges. When I need to look into my mail server the same applies: I can check log files just as easily. Of course this all depends on the situation and what you need to do.

The best reason for me to avoid using the root account all the time is because making a mistake as root will more than often have much dire results than doing the same as John Doe.

However, the reason why it's bad to allow the root user to directly log on over the network is security. The simplest example: brute force attacks. People know there's a root account present and will most likely try to gain brute force entry. Thus it's safer to disallow logging on entirely so that they can never abuse this.

To some extend this safety measure can be compared with why you should never use 1 password for all your websites or all your servers. Most of the time there's no problem at all and it just works as expected. Also a whole lot easier.

Until some day one of those websites, or servers, gets compromised for whatever reason. Then it depends on your own security measures if this disaster is going to spread out.
 
I don't use sudo, because I hate the idea that anyone, rather than the root user has the power to do administrative tasks. However, I am not dealing with a server, I am using FreeBSD on my home desktop machine, and I only use the root account for administration. Anything related to Internet/X.Org goes strictly through the regular account, or you are inviting danger with your bad practices.

I am no expert, but where I worked we usually logged in to our computers (cluster) through SSH. There we had no rights. In my opinion this is also not good -- what if a user has to install a program? In such cases I would use a jail, where "jailed root is less than the real root" (it would be nice if jailed roots would be called wardens, since they're overlooking the jail).

I didn't know about what @phoenix suggested before, so having those commands logged is definitely a good thing, and there definitely are benefits to using sudo. It would be nice to have certain commands set to be logged, regardless of the user.

In the end of the day, it really depends on the setup. Here are some important points you must take into the consideration:
  1. What will that machine be used for?
  2. Who has (physical) access to it?
  3. Who (potentially) has network access to it?
  4. How do I gain access the machine?
  5. How do I (as the administrator) trust the users?
  6. How do the users trust each other?
After you take these into the account you can start thinking of ways to secure the system.
 
Last edited by a moderator:
In addition to various other benefits listed above, sudo also allows you to give users root access without needing to inform everybody of the new root password when one of them leaves.

If you force everybody to use root or su, then if you have say, ten admin staff and one leaves, you need to re-distribute the root password to ten people.

If someone leaves and you're running sudo? Remove them from /etc/sudoers, change the root password (in case they set it somehow - randomly generate a new root password and lock it in a safe) and get on with life.
 
jozze said:
I don't use sudo, because I hate the idea that anyone, rather than root user has the power to do administrative tasks.
If you're doing something with UID 0, then you are root. Unless "root" is the name of a person who has access to your machine. sshd runs as root and changes to the UID of of the user logging in. When you run sudo, the suid bit causes the process to become root, as if it was started by root. You add users to the wheel group in place of giving them the root password so you don't have to send a new root password out to everyone every time an admin leaves. It's like using an RFID lock on "the door to becoming root" instead of passing out metal keys.

One other point worth mentioning is that if a user who can sudo logs in via private key over ssh, the password prompt ensures that someone who's acquired that key also needs to acquire the password of the user in order to sudo. You can also use the PAM configuration to e.g. allow network logins using Kerberos authentication but require a Unix password for sudo.

Kevin Barry
 
I guess @jozze is referring to how just about all Linux distros and also OS X have setup their security/sudo which is to allow switching to superuser privilegdes to any registered user that is not the guest user based on their own username/password. It's pretty terrible practice from the security POV but those systems are meant for less than fully computer literates who wouldn't understand why they suddenly had to remember another username/password combo to just install software for example.

Shameless plug: su(1) based on ssh-agent(1) forwarded keys, can be set up so that the users (SSH public keys) allowed to su(1) to root are specified in a file editable only by the superuser. HOWTO written by yours truly.

http://forums.freebsd.org/showthread.php?t=35645
 
Last edited by a moderator:
fonz said:
On FreeBSD that would be /usr/local/etc/sudoers ;)

Haha, my bad.

Of course you should just run visudo to do it, which is why I haven't edited the file directly for about 15 years, since I was on a Solaris 2.5 box :)
 
kpa said:
I guess @jozze is referring to how just about all Linux distros and also OS X have setup their security/sudo which is to allow switching to superuser privilegdes to any registered user that is not the guest user based on their own username/password.

I was pretty sure they needed to be deemed a computer administrator (tickbox in the user account tool) - which is (from memory) on by default for the first created user account (in OS X) but certainly not other accounts. I'll check on my OS X box this evening.

No idea what Linux does these days, but nothing they do surprises me any more.
 
Last edited by a moderator:
Oops yes, it's only true for the first account at least on OS X.

However, on an average machine your account very likely has computer administrator priviledges unless your machine was set up by someone else for you so that your user account is just a normal account.
 
kpa said:
Oops yes, it's only true for the first account at least on OS X.

However, on an average machine your account very likely has computer administrator priviledges unless your machine was set up by someone else for you so that your user account is just a normal account.

True.

Which is by design - if you, the owner/user of a computer need to make a change, being able to re-authenticate yourself to make the change is good, yes?

:)

Far better than just running as root, where you may accidentally perform a command that would do damage to the OS without being prompted for elevated privileges.
 
In my opinion, the advantage of using sudo(8) is that:
  • The user is forced to write an extra four letters to execute a command, and this can make him to think about what is doing (ok, one could also do a sudo sh, but that is another story).
  • You can configure and profile every single user and command, and this can be done on multiple hosts. In my previous job we had several servers with almost the same functionality, and therefore having a single file scattered across them made me feel at home!
  • You can log user's activity (ok, avoiding sudo sh...).
  • you will not work as root. There is nothing bad in working as root, and sometimes it has to be done, but come on, at least one time it happened that you removed some files accidentally...not being able to do that at least make you think at what you are doing.
  • You can enable some script/web/ERP to execute some special OS level task thru the mere mortals.

I had a (luckily) short experience of working on a server with a shared root account and all files (even text) with 777 permissions, it was a complete disaster. You did not know who did a change, who removed it, everyone was enable to do everything... it could work only if you are using a single account computer, and even in such situation you will appreciate not working like that.
 
Well, like I said, using/not using sudo depends on the circumstances -- for my home machine I wouldn't use it, since I'm the only one literate enough to touch it. If you're administrating a company's grid of computers it's a different story.

Regarding my last point (although I don't know much about security): many people are focusing on network attacks, but off-line (e.g. physical) attacks are also possible and dangerous, but are often (from my experiences at least) forgotten. See this video. As @ShelLuser suggested, you have to take this into consideration when you're configuring sudo, and your system in general.
 
Last edited by a moderator:
fluca1978 said:
(ok, one could also do a sudo sh, but that is another story).
That's why I generally recommend not allowing that sort of thing; it essentially defeats the entire purpose of sudo. On the flip side, it may take some effort configuring sudo to allow specific users to execute specific commands without being too restrictive.
 
But I am still thinking, that writing a configuration for sudo is no easy task if the environment is a little bit bigger (for example one team administrate the OS, one team the databases and one team the application).

We also have some departments which are using sudo in combination with LDAP, but they had to fit their configuration several times, because of the shell-escapes of several commands which were not obvious.

So as always: It depends :)

Regards
Markus
 
storvi_net said:
But I am still thinking, that writing a configuration for sudo is no easy task if the environment is a little bit bigger
Indeed it isn't. That's the flip side I was referring to ;)
 
Regarding logging, it won't be effective if the sudoer doesn't want it to be, mostly because he/she can just modify /var/log/messages to remove or change the logged commands. You really have to go out of your way to prevent circumventing the logging: you either need to use some MAC trickery, mess with kern.securelevel, or monitor syslog remotely. I personally run a daemon that emails me immediately if /var/log/messages has a change other than appending.

Regarding the complexity of sudo configuration, deny-by-exception won't work, but allow-by-exception will usually work. Any sort of differentiation you make between sudoers will be somewhat flimsy, so you're better off just having a single class of sudoers and set up MAC if you need something more fine-grained than that.

Kevin Barry
 
That is a good point. In my opinion an upright logging just can be implemented with a kind of jumpbox in front of the server. On this jumpbox the admin of the target system just has user-rights and all actions are logged (probably by using script or X-Recording). The administrator of the jumpbox MUST be another person/team (for example the security admins).

If you want to apply such a setting there are several other open issues to solve (for example the data privacy stuff and the rights (by law) of the admins).

Markus
 
Back
Top