11 ms·

> limits the number of people who are able to su to root. Is irrelevant and archaic for many, many servers (99%) of ones I've worked on last 20yrs (web/interne

> limits the number of people who are able to su to root. Is irrelevant and archaic for many, many servers (99%) of ones I've worked on last 20yrs (web/internet servers vs file/print/lan type servers. The only accounts who can login and get a shell are the same set of accounts who can su root to almost every server I'm involved with.

bostonpete 16y ago
That may be true of servers, but there are lots of uses of Linux besides servers...
ora600 16y ago
As a database consultant I can assure you there are great many servers on which I have a user, but no ability to "su root".
- bigiain 16y ago
  I bet if you were an "evil database consultant", you could get yourself a root shell on _many_ of those servers with a little bit of google fu. There is a startling amount of exploitable code waiting in just about every standard OS install for anybody with regular user privileges.
  - ora600 16y ago
    If I was evil and suicidal I could wipe up many companies by "drop database including backup". When you have DBA access to production databases, lack of root does not stand in the way of doing evil. It does stand in the way of using message logs to troubleshoot, checking contents of /proc to determine which directory a process is running from, tuning TCP parameters to maximize data transfer rates without nagging the sysadmins, etc.
    - bigiain 16y ago
      True. But a _properly evil_ non-suicidal and supremely confident evil DBA could, if they wanted too, exploit the box from a local user account, rootkit it, and tidy up after themselves to remove all trace of who did it. I suspect that's actually script-kiddy-able these days, if you know the target well enough there's probably an automated tool ready to do all that for you. (For evil-genius-DBA's bonus points for doing that via the database instead of the shell and censoring traces from the db logs too...)
bigiain 16y ago
+1 On everything I'm responsible for, it's assumed that if you've got shell or if you've got permission to upload executable code, you've got the ability to get root. I'm prepared to keep on top of server security enough to protect against remote-root exploits (with reasonably short zero-day exposure times), but there's no way I'm going to be able to keep every little utility shipped with a useable linux distribution up-to-date and secure. If Tripwire or Snort or the logfiles show unexpected filesystem changes, we reimage the OS and restore the data from backups.

bostonpete 16y ago

That may be true of servers, but there are lots of uses of Linux besides servers...

ora600 16y ago

As a database consultant I can assure you there are great many servers on which I have a user, but no ability to "su root".

bigiain 16y ago
I bet if you were an "evil database consultant", you could get yourself a root shell on _many_ of those servers with a little bit of google fu. There is a startling amount of exploitable code waiting in just about every standard OS install for anybody with regular user privileges.
- ora600 16y ago
  If I was evil and suicidal I could wipe up many companies by "drop database including backup". When you have DBA access to production databases, lack of root does not stand in the way of doing evil. It does stand in the way of using message logs to troubleshoot, checking contents of /proc to determine which directory a process is running from, tuning TCP parameters to maximize data transfer rates without nagging the sysadmins, etc.
  - bigiain 16y ago
    True. But a _properly evil_ non-suicidal and supremely confident evil DBA could, if they wanted too, exploit the box from a local user account, rootkit it, and tidy up after themselves to remove all trace of who did it. I suspect that's actually script-kiddy-able these days, if you know the target well enough there's probably an automated tool ready to do all that for you. (For evil-genius-DBA's bonus points for doing that via the database instead of the shell and censoring traces from the db logs too...)

bigiain 16y ago

+1 On everything I'm responsible for, it's assumed that if you've got shell or if you've got permission to upload executable code, you've got the ability to get root. I'm prepared to keep on top of server security enough to protect against remote-root exploits (with reasonably short zero-day exposure times), but there's no way I'm going to be able to keep every little utility shipped with a useable linux distribution up-to-date and secure. If Tripwire or Snort or the logfiles show unexpected filesystem changes, we reimage the OS and restore the data from backups.