3 ms·

passwd Change the root password to something long and complex. And bam! Not even a full paragraph in and security fail. root login should be disabled complete

passwd Change the root password to something long and complex. And bam! Not even a full paragraph in and security fail. root login should be disabled completely, and all use of privileges should be through sudo. Debian sets this up for you automatically upon install if you supply an empty root password. Of course, disabling root is just the beginning (and the first user created needs to be locked down, as they are now essentially root).

marcosdumay 14y ago
> root login should be disabled completely Would you care to explain why?
- npsimons 14y ago
  The foremost reason is that root is carte blanche to ruin a system. This may be fine for a developer seat or even a desktop that is not critical infrastructure (shared), but on a multi-user system (and this includes things such as email and web servers), you really should have a "think twice" prompt, along with logging of who did what and when (eg, sudo). Even if you leave root as ssh key only login, then once an attacker has gained that key (or found a remote exploit), they don't need a password; they're root. Setup administrator users who are given a limited set of sudo commands and only allow them to login via SSH with keys and require complex passwords for sudo, and that's multiple layers of protection and logging. Nothing's perfect, but it has long been recognized that root is a big gaping hole in UNIX security; that's why things like SELinux and RBAC were created, and it's why Windows for so long was so insecure (ie, the main user was essentially passwordless root).
  - marcosdumay 14y ago
    The problem of sudo is that it's so easy to make a mistake in your command (and in sudoers). That's a security flaw in itself. Also, you can always sudo bash, or sudo su. You have a point about that extra password. But not about SELinux and RBAC being created because of that, nor in comparing the security of a system with root to one where eveybody is root. All said, I'm still unconvinced. The logging isn't that usefull (I've tried it), and the extra password isn't relevant enough. Also, none of them will detain a malicious user (Linux has very week defenses against you grabing your own password).
    - npsimons 14y ago
      Also, you can always sudo bash, or sudo su. Not if you lock down sudo properly. If you're just doing "username ALL=(ALL) ALL", then yes, you've got a big gaping hole. Even for my main administrator accounts sudo is locked down to a specific list of commands. As for logging, I get an email every time sudo is run on my systems. It's not built into sudo, but there are multiple packages which take care of such things. You can even set it up to do remote logging to an external source. As I understand RBAC, it was specifically created to break up the responsibilities of root to different roles with privileges which were then assigned based on different access control mechanisms. Linux has very week defenses against you grabing your own password. This sounds like a major hole which I'm sure the security community would love to hear about; care to elaborate? Just to pick one example, how does one grab a password entered over an ssh session?
pfranz 14y ago
I was installing Arch on RaspberryPi and tried disabling root (since I had seen it done on other distros). Not long after I was fiddling with LVM. When I rebooted it halted on my fstab which couldn't find my VolumeGroups and required my root password to continue booting. I ended up popping out the drive and mounting it on another box, changed my fstab to noauto, got things to boot and reenabled root. I figure distros that disable root are setup for these corner-cases where root is required. The other obvious case is if you're using LDAP and the network is down. Maybe I haven't looked in the right places, but I haven't heard these things discussed.

marcosdumay 14y ago

> root login should be disabled completely Would you care to explain why?

npsimons 14y ago
The foremost reason is that root is carte blanche to ruin a system. This may be fine for a developer seat or even a desktop that is not critical infrastructure (shared), but on a multi-user system (and this includes things such as email and web servers), you really should have a "think twice" prompt, along with logging of who did what and when (eg, sudo). Even if you leave root as ssh key only login, then once an attacker has gained that key (or found a remote exploit), they don't need a password; they're root. Setup administrator users who are given a limited set of sudo commands and only allow them to login via SSH with keys and require complex passwords for sudo, and that's multiple layers of protection and logging. Nothing's perfect, but it has long been recognized that root is a big gaping hole in UNIX security; that's why things like SELinux and RBAC were created, and it's why Windows for so long was so insecure (ie, the main user was essentially passwordless root).
- marcosdumay 14y ago
  The problem of sudo is that it's so easy to make a mistake in your command (and in sudoers). That's a security flaw in itself. Also, you can always sudo bash, or sudo su. You have a point about that extra password. But not about SELinux and RBAC being created because of that, nor in comparing the security of a system with root to one where eveybody is root. All said, I'm still unconvinced. The logging isn't that usefull (I've tried it), and the extra password isn't relevant enough. Also, none of them will detain a malicious user (Linux has very week defenses against you grabing your own password).
  - npsimons 14y ago
    Also, you can always sudo bash, or sudo su. Not if you lock down sudo properly. If you're just doing "username ALL=(ALL) ALL", then yes, you've got a big gaping hole. Even for my main administrator accounts sudo is locked down to a specific list of commands. As for logging, I get an email every time sudo is run on my systems. It's not built into sudo, but there are multiple packages which take care of such things. You can even set it up to do remote logging to an external source. As I understand RBAC, it was specifically created to break up the responsibilities of root to different roles with privileges which were then assigned based on different access control mechanisms. Linux has very week defenses against you grabing your own password. This sounds like a major hole which I'm sure the security community would love to hear about; care to elaborate? Just to pick one example, how does one grab a password entered over an ssh session?

pfranz 14y ago

I was installing Arch on RaspberryPi and tried disabling root (since I had seen it done on other distros). Not long after I was fiddling with LVM. When I rebooted it halted on my fstab which couldn't find my VolumeGroups and required my root password to continue booting. I ended up popping out the drive and mounting it on another box, changed my fstab to noauto, got things to boot and reenabled root. I figure distros that disable root are setup for these corner-cases where root is required. The other obvious case is if you're using LDAP and the network is down. Maybe I haven't looked in the right places, but I haven't heard these things discussed.