5 ms·

strace/ptrace gives you huge amount of power. I had a discussion once with admins at my company that wanted to convert servers to have AD accounts in a naive w

strace/ptrace gives you huge amount of power. I had a discussion once with admins at my company that wanted to convert servers to have AD accounts in a naive way. The discussion could be shortened to something like this: Me: please, don't convert servers to AD because my password will be available to everybody as everybody has root on test environment. Admins: no, this is perfectly safe. Me: Guys, once you have root on machine you can do everything including accessing passwords as they are being typed. Admins: No, not possible. Perfectly safe. Me: Here, I ran the tool using ptrace from root account, here is a list of all accounts and passwords of all users using test env. This is actually read() call at some point, you just need to be able to filter it out from strace output. Admins: Wtf! You are going to get fired!

tw04 7y ago
I'm not sure what AD has to do with the fact as root, you have a huge amount of power on ANY box and abusing it will get you fired. strace/ptrace is just another tool in that toolbox that you can use maliciously. Your company either runs in a model where it trusts the employees or it doesn't. If it doesn't trust the employees they shouldn't be giving ANY of them root on a shared system.
- filleokus 7y ago
  In my case, I'm using a different, easy password, for test servers that contain no important production data or are in a especially privileged network position. If they were connected to AD, I would be forced to present my "real" password. On production servers on the other hand, the amount of people with root is probably much smaller, and there might be bigger wins by being able to centrally enforce password policies or whatever the sysadmins want to do.
  - lmilcin 7y ago
    That was exactly the point. I had separate password on each box (which I did not have to use normally because I use it only to setup ssh key).
  - tw04 7y ago
    So create a second AD account for the test environment like most shops do?
    - ghjkldsf 7y ago
      But then you don't get the joy of throwing the baby out with the bath water. 90% of the time someone insists AD is too insecure for them, it's because they're unwilling to maintain hygiene (logging into an untrusted machines with overscoped credentials 8 times a day), or unwilling to use the provided security features (what do you mean use kerberized services? ldap binds work just find and give me an anti-ad security straw man!)
- mlyle 7y ago
  Shared root on an unimportant system with disposable creds is different on shared root on a system that uses (reusable) org-wide creds.
spydum 7y ago
such is the curse of privileged access.. Even if they hadn't enabled AD, a privileged admin could have stolen ssh keys, or passwords by launching nefarious sshd's or other daemons. You could make the argument "but that would have been detected", but then so could watching for "strace" or "ptrace" invocations. At some point, you have to trust the people with privileged access, and make sure they aren't abusing it.
- lmilcin 7y ago
  SSH keys not so much, because you keep your private key on your local machine. With poorly implemented AD (think telnet/ssh login app asking for password), on the other hand, you get password transmitted to the other box. At some point some application performs read() to actually receive it.
  - shawnz 7y ago
    You could use GSSAPI auth with SSH. This is also a good argument for having a test AD domain to use in your test environment.
- rcxdude 7y ago
  I think the point is that using AD would mean the OP would be forced to use the same password to access the test system as the prod system. Otherwise, they would use different passwords and no matter how nefarious any admin on the test system was they wouldn't get access to the prod system through it.
  - jldugger 7y ago
    It's entirely possible to run separate Kerberos realms for test and prod.
  - yrro 7y ago
    If using AD then why on earth not forgo passwords entirely and use Kerberos to access these systems...
staticassertion 7y ago
> including accessing passwords as they are being typed. If you're running X you don't even need root :(
- lmilcin 7y ago
  That's not necessarily true. You can run X as user. You can run X locally and run the app on remote server using local X server over SSH tunnel using SSH keys. I do this about as frequently as I need to install something on remote server that has graphical installer. Not sure why people think thought this is a good idea but a huge amount of commercial software in 2000s had that kind of installation process.
  - icedchai 7y ago
    Certain OSes, one of them being SGI IRIX 5.x, used to ship with X security disabled. This meant your display was completely open to the world, the equivalent of running "xhost +" In the 90's, firewalls were uncommon, so literally anyone on the Internet could sniff your keyboard or pop up windows on your display. Or, better yet, xmelt it. This resulted in LOTS of mayhem.
    - elygre 7y ago
      Many years ago, a young consultant was working at a client site on a SunOS box. Suddenly, the machine started playing the, let's call it the restaurant scene, from "When Harry met Sally." Yeah, it got awkward real fast...

tw04 7y ago

I'm not sure what AD has to do with the fact as root, you have a huge amount of power on ANY box and abusing it will get you fired. strace/ptrace is just another tool in that toolbox that you can use maliciously. Your company either runs in a model where it trusts the employees or it doesn't. If it doesn't trust the employees they shouldn't be giving ANY of them root on a shared system.

filleokus 7y ago
In my case, I'm using a different, easy password, for test servers that contain no important production data or are in a especially privileged network position. If they were connected to AD, I would be forced to present my "real" password. On production servers on the other hand, the amount of people with root is probably much smaller, and there might be bigger wins by being able to centrally enforce password policies or whatever the sysadmins want to do.
- lmilcin 7y ago
  That was exactly the point. I had separate password on each box (which I did not have to use normally because I use it only to setup ssh key).
- tw04 7y ago
  So create a second AD account for the test environment like most shops do?
  - ghjkldsf 7y ago
    But then you don't get the joy of throwing the baby out with the bath water. 90% of the time someone insists AD is too insecure for them, it's because they're unwilling to maintain hygiene (logging into an untrusted machines with overscoped credentials 8 times a day), or unwilling to use the provided security features (what do you mean use kerberized services? ldap binds work just find and give me an anti-ad security straw man!)
mlyle 7y ago
Shared root on an unimportant system with disposable creds is different on shared root on a system that uses (reusable) org-wide creds.

spydum 7y ago

such is the curse of privileged access.. Even if they hadn't enabled AD, a privileged admin could have stolen ssh keys, or passwords by launching nefarious sshd's or other daemons. You could make the argument "but that would have been detected", but then so could watching for "strace" or "ptrace" invocations. At some point, you have to trust the people with privileged access, and make sure they aren't abusing it.

lmilcin 7y ago
SSH keys not so much, because you keep your private key on your local machine. With poorly implemented AD (think telnet/ssh login app asking for password), on the other hand, you get password transmitted to the other box. At some point some application performs read() to actually receive it.
- shawnz 7y ago
  You could use GSSAPI auth with SSH. This is also a good argument for having a test AD domain to use in your test environment.
rcxdude 7y ago
I think the point is that using AD would mean the OP would be forced to use the same password to access the test system as the prod system. Otherwise, they would use different passwords and no matter how nefarious any admin on the test system was they wouldn't get access to the prod system through it.
- jldugger 7y ago
  It's entirely possible to run separate Kerberos realms for test and prod.
- yrro 7y ago
  If using AD then why on earth not forgo passwords entirely and use Kerberos to access these systems...

staticassertion 7y ago

> including accessing passwords as they are being typed. If you're running X you don't even need root :(

lmilcin 7y ago
That's not necessarily true. You can run X as user. You can run X locally and run the app on remote server using local X server over SSH tunnel using SSH keys. I do this about as frequently as I need to install something on remote server that has graphical installer. Not sure why people think thought this is a good idea but a huge amount of commercial software in 2000s had that kind of installation process.
- icedchai 7y ago
  Certain OSes, one of them being SGI IRIX 5.x, used to ship with X security disabled. This meant your display was completely open to the world, the equivalent of running "xhost +" In the 90's, firewalls were uncommon, so literally anyone on the Internet could sniff your keyboard or pop up windows on your display. Or, better yet, xmelt it. This resulted in LOTS of mayhem.
  - elygre 7y ago
    Many years ago, a young consultant was working at a client site on a SunOS box. Suddenly, the machine started playing the, let's call it the restaurant scene, from "When Harry met Sally." Yeah, it got awkward real fast...