# sudo and root



## xy16644 (Jun 14, 2013)

I have two questions:

 What is the maximum length of a root password in FreeBSD 9.1? (if any) 

 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.


----------



## ta0kira (Jun 14, 2013)

xy16644 said:
			
		

> What is the maximum length of a root password in FreeBSD 9.1? (if any)
> 
> 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


----------



## ShelLuser (Jun 14, 2013)

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:


```
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:


```
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:


```
[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.


----------



## gordon@ (Jun 16, 2013)

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.


----------



## storvi_net (Jun 16, 2013)

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


----------



## ta0kira (Jun 16, 2013)

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


----------



## throAU (Jun 27, 2013)

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.


----------



## phoenix (Jun 27, 2013)

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.


----------



## ShelLuser (Jun 27, 2013)

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.


----------



## jozze (Jun 27, 2013)

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:

 What will that machine be used for?
 Who has (physical) access to it?
 Who (potentially) has network access to it?
 How do I gain access the machine?
 How do I (as the administrator) trust the users?
 How do the users trust each other?
After you take these into the account you can start thinking of ways to secure the system.


----------



## throAU (Jun 28, 2013)

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? *R*emove 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.


----------



## ta0kira (Jun 28, 2013)

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


----------



## fonz (Jun 28, 2013)

throAU said:
			
		

> Remove them from /etc/sudoers


On FreeBSD that would be */usr/local*/etc/sudoers


----------



## kpa (Jun 28, 2013)

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


----------



## throAU (Jun 28, 2013)

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


----------



## throAU (Jun 28, 2013)

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.


----------



## kpa (Jun 28, 2013)

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.


----------



## throAU (Jun 28, 2013)

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.


----------



## fluca1978 (Jun 28, 2013)

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.


----------



## jozze (Jun 28, 2013)

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.


----------



## fonz (Jun 28, 2013)

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.


----------



## storvi_net (Jun 28, 2013)

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


----------



## fonz (Jun 28, 2013)

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


----------



## ta0kira (Jun 30, 2013)

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


----------



## storvi_net (Jun 30, 2013)

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


----------



## xy16644 (Jun 30, 2013)

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.


----------



## fonz (Jun 30, 2013)

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


----------



## storvi_net (Jun 30, 2013)

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


----------



## ta0kira (Jul 1, 2013)

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


----------



## fluca1978 (Jul 1, 2013)

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.


----------



## ta0kira (Jul 1, 2013)

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


----------



## storvi_net (Jul 1, 2013)

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


----------



## chatwizrd (Jul 1, 2013)

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.


----------



## ta0kira (Jul 1, 2013)

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


----------



## kpa (Jul 1, 2013)

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:


```
: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.


----------



## throAU (Jul 2, 2013)

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.


----------



## fluca1978 (Jul 2, 2013)

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.


----------



## ta0kira (Jul 2, 2013)

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:
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.
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


----------

