4 ms·

If someone logs in directly as root, how do you track root access? Given that you should be discouraging root use and using sudo or scripts to automate admin ta

If someone logs in directly as root, how do you track root access? Given that you should be discouraging root use and using sudo or scripts to automate admin tasks, why are you encouraging admins to log on as root?

belorn 14y ago
Discouraging root usage is common in desktop and laptop environments, and for developers on production servers. For admins on servers, root use is basically required for all commands, and sudo would not improve the security at all. Commonly, I track access through environment variables (configuration on the ssh client), and documentation that each administrator do after finishing a task. As one should not recruit administrators that do rm -rf /, tracking (blame) is of an lesser importance and documentation a much higher one. If more was required, I would go with kerberos+ldap approach without anyone using local root user accounts at all.
- lotsofcows 14y ago
  I am the admin. I use the root account as little as possible. I do employ admins that don't rm -rf / by employing admins who don't hack on live as root. Knowing who does what is paramount for resolving problems particularly in admins' work practices.
moe 14y ago
If someone logs in directly as root, how do you track root access? By their SSH-key and IP address (both of which are logged to a remote syslog-server). Given that you should be discouraging root use and using sudo or scripts to automate admin tasks, why are you encouraging admins to log on as root? That is a false premise. I'd never encourage anyone to use "sudo" because it's a source of errors; people get the escaping and context wrong all the time, doing things that they didn't intend, and wasting precious productivity on getting the incantation just right. It also doesn't add any meaningful security, it's a red herring. If you need a dependable audit-trail then sudo is worth zilch. In that case you're looking at SELinux, auditd and friends. If you don't need that trail (which is most people) then sudo is a ball on a chain and a false sense of security. Local privilege escalation exploits are dime a dozen, any shell-account can be upgraded to root by a dedicated attacker anyway (sometimes via sudo itself, as seen in in the recent sudo exploit...). Oh, and let's not forget: If you enable a user to do anything meaningful with sudo then that normally includes giving him a way to write arbitrary files as root...
- lotsofcows 14y ago
  Logging the ssh key used sounds interesting - not something I've tried before. I think you're doing something wrong with sudo. I'm not talking about "reentering your password" in the Ubuntu or Mac sense. I'm talking about giving access to specific limited commands. And what distro are you running where local privilege escalation is common?
  - moe 14y ago
    I'm talking about giving access to specific limited commands. By definition the set is either so limited as to be essentially useless, or it opens (usually multiple) straightforward paths to a root-shell. Pretty much all sudoers-files I have seen fall in the latter category ("but he can only write the apache config-file!"). And what distro are you running where local privilege escalation is common? https://www.google.com/search?q=linux+local+privilege+escalation https://www.google.com/search?q=linux+local+privilege+escala...
    - lotsofcows 14y ago
      "only write the apache config-file" Ha! Local privilege: yeah, that's a lot but over a long time span and none should be current on decently maintained box. I've never even seen anyone attempt a 0 day on my boxen.

belorn 14y ago

Discouraging root usage is common in desktop and laptop environments, and for developers on production servers. For admins on servers, root use is basically required for all commands, and sudo would not improve the security at all. Commonly, I track access through environment variables (configuration on the ssh client), and documentation that each administrator do after finishing a task. As one should not recruit administrators that do rm -rf /, tracking (blame) is of an lesser importance and documentation a much higher one. If more was required, I would go with kerberos+ldap approach without anyone using local root user accounts at all.

lotsofcows 14y ago
I am the admin. I use the root account as little as possible. I do employ admins that don't rm -rf / by employing admins who don't hack on live as root. Knowing who does what is paramount for resolving problems particularly in admins' work practices.

moe 14y ago

If someone logs in directly as root, how do you track root access? By their SSH-key and IP address (both of which are logged to a remote syslog-server). Given that you should be discouraging root use and using sudo or scripts to automate admin tasks, why are you encouraging admins to log on as root? That is a false premise. I'd never encourage anyone to use "sudo" because it's a source of errors; people get the escaping and context wrong all the time, doing things that they didn't intend, and wasting precious productivity on getting the incantation just right. It also doesn't add any meaningful security, it's a red herring. If you need a dependable audit-trail then sudo is worth zilch. In that case you're looking at SELinux, auditd and friends. If you don't need that trail (which is most people) then sudo is a ball on a chain and a false sense of security. Local privilege escalation exploits are dime a dozen, any shell-account can be upgraded to root by a dedicated attacker anyway (sometimes via sudo itself, as seen in in the recent sudo exploit...). Oh, and let's not forget: If you enable a user to do anything meaningful with sudo then that normally includes giving him a way to write arbitrary files as root...

lotsofcows 14y ago
Logging the ssh key used sounds interesting - not something I've tried before. I think you're doing something wrong with sudo. I'm not talking about "reentering your password" in the Ubuntu or Mac sense. I'm talking about giving access to specific limited commands. And what distro are you running where local privilege escalation is common?
- moe 14y ago
  I'm talking about giving access to specific limited commands. By definition the set is either so limited as to be essentially useless, or it opens (usually multiple) straightforward paths to a root-shell. Pretty much all sudoers-files I have seen fall in the latter category ("but he can only write the apache config-file!"). And what distro are you running where local privilege escalation is common? https://www.google.com/search?q=linux+local+privilege+escalation https://www.google.com/search?q=linux+local+privilege+escala...
  - lotsofcows 14y ago
    "only write the apache config-file" Ha! Local privilege: yeah, that's a lot but over a long time span and none should be current on decently maintained box. I've never even seen anyone attempt a 0 day on my boxen.