sudo and root

Thanks to all for all your replies.

When I build my new server I will be setting a very VERY long root password (possibly 128 characters in length) as I will almost never use the root account. I'll also use sudo and login with my own account that will be a member of the wheel group. I also use key based authentication with a smartcard when I login to SSH.
 
ta0kira said:
mostly because he/she can just modify /var/log/messages to remove or change the logged commands.
That of course depends on what is allowed in /usr/local/etc/sudoers ;)
 
xy16644 said:
Thanks to all for all your replies.

When I build my new server I will be setting a very VERY long root password (possibly 128 characters in length) as I will almost never use the root account. I'll also use sudo and login with my own account that will be a member of the wheel group. I also use key based authentication with a smartcard when I login to SSH.

If you do so, take care about the setting "PasswordAuthentication" in sshd_config, to make sure that nobody tries to authenticate with your password.

The password should just be there in case of an emergency, when you have to sit in front of the server (console) or login to the KVM interface.

Markus
 
fonz said:
That of course depends on what is allowed in /usr/local/etc/sudoers ;)
Are you going to deny access to every binary that can eventually lead to editing a file? If not, you'd have to limit their access to a specific editor that has no capability of interactively opening a file for editing, and deny access to all binaries that are capable of running any sort of command. So, you'd have to deny them access to ee, emacs, and vi, not to mention all shells and interpreted languages, make, and even find. That's why I said that "can sudo"/"can't sudo" is the only effective distinction you can make without getting into kernel-level enforcement or outside monitoring.

Also, remember that security is as much to mitigate compromised accounts as it is to confine users in the gray area of trust.

Kevin Barry
 
storvi_net said:
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).

Sounds a little complicated to me, and introduces another point of failure. Probably this is fine for large and complex environments, but for small-to-medium deployments sudo is just fine.


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 (for example one team administrate the OS, one team the databases and one team the application).

Yes, sharing the root password is much simpler, but if we want to try to make the system safier, we have to spend some time. I believe configuring sudo can be annoying at first, since youy will probably lock more users than you want to, but then it will become quite easy to manage permissions.


ta0kira said:
Are you going to deny access to every binary that can eventually lead to editing a file? If not, you'd have to limit their access to a specific editor that has no capability of interactively opening a file for editing, and deny access to all binaries that are capable of running any sort of command. So, you'd have to deny them access to ee, emacs, and vi, not to mention all shells and interpreted languages, make, and even find. That's why I said that "can sudo"/"can't sudo" is the only effective distinction you can make without getting into kernel-level enforcement or outside monitoring.

No, but you can set file flags and prevent users in the sudoers to remove them.
 
fluca1978 said:
No, but you can set file flags and prevent users in the sudoers to remove them.
Yes, but that's kernel-level enforcement, and you have to change kern.securelevel for it to be effective, which means that no user can modify it (not even newsyslog.) That's clearly a side-effect that extends beyond the scope of the sudo program. Once sudo executes its command, the only security that remains (vs. a root session) are attributes of the process, i.e. uid, groups, privilege status, MAC label, jailed status, etc. sudoers only operates on the first two.

Kevin Barry
 
fluca1978 said:
Yes, sharing the root password is much simpler, but if we want to try to make the system safier, we have to spend some time.

We do not share the root password. The root password is just known by the password manager or is inside a safe or on a device like the Yubikey. It is just used for console access. With our administration concept it is changed after use (or the Yubikey is returned to the safe). All daily business is done by using SSH keys (on smartcards).

We do not use sudo, because the described scenario is accepted and ok for us (and I think quite secure).

Markus
 
There is barely any reason to ever need sudo. We never allow it on any servers. There are only a few times I have ever found it of any use in over 20 years.
 
chatwizrd said:
There is barely any reason to ever need sudo. We never allow it on any servers. There are only a few times I have ever found it of any use in over 20 years.
It certainly doesn't solve a unique problem, so it's never really "needed" unless you disable the root account. It solves a problem that can be easily handled via the other means suggested in this thread, each of which has its own set of security problems and admin inconveniences. It all relates to who can become root and how they can do so, but for the most part it's a process of authentication and not authorization. There are more pertinent security considerations than the means of becoming root, such as controlling what can be done when one is root (e.g. with the MAC framework.)

Kevin Barry
 
xy16644 said:
Thanks to all for all your replies.

When I build my new server I will be setting a very VERY long root password (possibly 128 characters in length) as I will almost never use the root account. I'll also use sudo and login with my own account that will be a member of the wheel group. I also use key based authentication with a smartcard when I login to SSH.

That's quite an overkill, a 16 character password that has enough randomness is enough *). Check that your system is using the SHA512 hashes for passwords, they can be identified from the hashes in /etc/master.passwd if they start with the string "$6$". If it's not already the default has SHA512 can be made the default in /etc/login.conf by editing the passwd_format field to read:

Code:
    :passwd_format=sha512:\

Update the /etc/login.conf.db file:

cap_mkdb /etc/login.conf

And then reset the passwords with passwd(1).

*) Try to keep the information about how long password you chose a secret as well. If you somehow expose the length of the password to crackers it may be too much information already. The password hashes themselves do not reveal the length of the password used because of their nature that is "many to one" and the output of the hashing is of fixed length.
 
If someone is able to authenticate to any service over the network using the root password, there is something wrong. Use SSH keys, disable root for other services, etc.

If you use a password manager (assuming so, with a password that long) then I guess there's little downside to using a more complex password, except for when you need to log into root (typically in an emergency in single user mode - in this case, the network and thus cut/paste from password manage may be unavailable) - which may make a 128 character password cause more inconvenience than it is worth.
 
ta0kira said:
Yes, but that's kernel-level enforcement, and you have to change kern.securelevel for it to be effective, which means that no user can modify it (not even newsyslog.) That's clearly a side-effect that extends beyond the scope of the sudo program. Once sudo executes its command, the only security that remains (vs. a root session) are attributes of the process, i.e. uid, groups, privilege status, MAC label, jailed status, etc. sudoers only operates on the first two.

Kevin Barry

I guess the point is that sudo should be thought as a command shell on steroids: it allows you to fine grain who and what can be done. However, it is clear that all commands have to deal with kernel security constraints.
With regard to the log manipulation issue, having the sappnd flag on a log file does not seems so scary to me, but probably I'm missing out something.
 
fluca1978 said:
I guess the point is that sudo should be thought as a command shell on steroids: it allows you to fine grain who and what can be done. However, it is clear that all commands have to deal with kernel security constraints.
With regard to the log manipulation issue, having the sappnd flag on a log file does not seems so scary to me, but probably I'm missing out something.
My points are:
  1. Whatever appearance of fine-grained control you have with sudoers, it isn't going to be as effective as you think. For example, maybe I'll allow someone to run /usr/bin/mail as root with no arguments, and no other command. Secure? No. That user can just set PAGER="sh -c 'ee < /dev/pts/0'" (or whatever the pty is) and start "reading mail", i.e. editing arbitrary files. Maybe I'll allow someone to add users. Fine. He/she can temporarily add a user with uid 0, sign in as that user and make the necessary changes, then remove the user. You immediately run into similar problems if you want to allow a sudoer to do anything else useful, like editing config files or installing ports. That's why I say that the only real distinction is between those who can sudo and those who can't.
  2. sappnd can be unset by any root process unless you set kern.securelevel to 1 or higher. That's a system-wide constraint that isn't fine-grained at all, and is meant to mitigate intrusions. sappnd will also prevent newsyslog from rotating the log file, so you'd have to restart the system and rotate the log manually every time it got too large.
Kevin Barry
 
Back
Top