sudo problems
-
@dashrender said in sudo problems:
@scottalanmiller said in sudo problems:
@pete-s said in sudo problems:
What are our options, except removing sudo altogether and require login from a privileged account?
Anything that allows sudo is a privileged account. Sudo isn't an alternative to having separate accounts, it's meant as an additional protection on accounts that are already designated as privileged. Just like on Windows.
So this is like an admin account that still trips over UAC, but doesn't require a password - just OK to continue?
Exactly! Windows copied it really closely.
-
I can prove the degree to which sudo exposes that it is allowing a privileged account to take an action compared to allowing access to a privileged account (which can be argued is the same thing, both are privileges, but sudo is more extreme of the original account being the privileged one.) Older tools, like su allow the user to move from using their own unprivileged account to using root (or something else) that is privileged. Sudo does not, sudo still acts as the original account which has been given admin level rights.
Here is how you can see it in action...
scott@ntg-scott-lnx-desk:/tmp$ sudo touch test1 scott@ntg-scott-lnx-desk:/tmp$ ll | grep test -rw-rw-r-- 1 scott scott 0 Jul 19 15:34 test0 -rw-rw-r-- 1 scott scott 0 Jul 19 15:34 test1Notice that when I made a file using sudo, it didn't make the file as root or any other account, the action was taken by the same account. Just in one case access to privileges was allowed and in the other case it was protected. But the account itself has the privileges in this case, just administered by the sudo mechanism.
-
@pete-s said in sudo problems:
And it feels insecure to simply remove the password requirement.
The beauty of cert based auth.
But really, any account that isn't allowed to sudo couldn't do it anyways. That sudo doesn't require a pw doesn't matter. Just like in Windows, if you don't have local admin privileges, UAC doesn't matter... unless you have the credentials of or access to an account that does.
-
@obsolesce said in sudo problems:
@pete-s said in sudo problems:
And it feels insecure to simply remove the password requirement.
The beauty of cert based auth.
But really, any account that isn't allowed to sudo couldn't do it anyways. That sudo doesn't require a pw doesn't matter. Just like in Windows, if you don't have local admin privileges, UAC doesn't matter... unless you have the credentials of or access to an account that does.
There IS an argument for sudo with password stopping a physical attack where someone watches you look away from the keyboard, then type while you are not looking. It's valid, but minor in most cases.
-
@scottalanmiller said in sudo problems:
@obsolesce said in sudo problems:
@pete-s said in sudo problems:
And it feels insecure to simply remove the password requirement.
The beauty of cert based auth.
But really, any account that isn't allowed to sudo couldn't do it anyways. That sudo doesn't require a pw doesn't matter. Just like in Windows, if you don't have local admin privileges, UAC doesn't matter... unless you have the credentials of or access to an account that does.
There IS an argument for sudo with password stopping a physical attack where someone watches you look away from the keyboard, then type while you are not looking. It's valid, but minor in most cases.
That's not sudo's responsibility or concern IMO. That's like the lock manufacturer for your front door wanting to keep people out after you already unlock the door and open it.
-
@obsolesce said in sudo problems:
@scottalanmiller said in sudo problems:
@obsolesce said in sudo problems:
@pete-s said in sudo problems:
And it feels insecure to simply remove the password requirement.
The beauty of cert based auth.
But really, any account that isn't allowed to sudo couldn't do it anyways. That sudo doesn't require a pw doesn't matter. Just like in Windows, if you don't have local admin privileges, UAC doesn't matter... unless you have the credentials of or access to an account that does.
There IS an argument for sudo with password stopping a physical attack where someone watches you look away from the keyboard, then type while you are not looking. It's valid, but minor in most cases.
That's not sudo's responsibility or concern IMO. That's like the lock manufacturer for your front door wanting to keep people out after you already unlock the door and open it.
It might not be its responsibility, but that is the top reason that people argue for its use.
-
Just have PAM verify the cert if you want the perceived second layer of auth.
-
@stacksofplates said in sudo problems:
Just have PAM verify the cert if you want the perceived second layer of auth.
Thanks, I had a look at that one before.
But then I had a look at this one as well:
https://engineering.fb.com/2016/09/12/security/scalable-and-secure-access-with-ssh/
Facebook uses shared accounts with ssh certificates. -
@scottalanmiller said in sudo problems:
The sudo mechanism is used to make privileged accounts safer. That's all. That's all that it can do, because any account with access to it is, by definition, already a privileged account. The privilege is the access to sudo. Sudo is a great tool that we use all the time because it truly makes privileged accounts dramatically safer than they were before. But it's one of those super dangerous things to start thinking that an account with sudo rights isn't privileged already, because it is.
Yeah, I like that. I think I've confused myself on what sudo actually does.
-
@pete-s said in sudo problems:
@scottalanmiller said in sudo problems:
The sudo mechanism is used to make privileged accounts safer. That's all. That's all that it can do, because any account with access to it is, by definition, already a privileged account. The privilege is the access to sudo. Sudo is a great tool that we use all the time because it truly makes privileged accounts dramatically safer than they were before. But it's one of those super dangerous things to start thinking that an account with sudo rights isn't privileged already, because it is.
Yeah, I like that. I think I've confused myself on what sudo actually does.
It's a great mechanism, don't get me wrong. I highly recommend it for most cases.
-
@pete-s said in sudo problems:
Facebook uses shared accounts with ssh certificates.
Actually quite common.
-
@scottalanmiller said in sudo problems:
@pete-s said in sudo problems:
We want to move to using ssh certificates on our servers and remove all passwords.
That's what we do.
Since when? What do you use to manage and generate certificates?
-
@scottalanmiller said in sudo problems:
I can prove the degree to which sudo exposes that it is allowing a privileged account to take an action compared to allowing access to a privileged account (which can be argued is the same thing, both are privileges, but sudo is more extreme of the original account being the privileged one.) Older tools, like su allow the user to move from using their own unprivileged account to using root (or something else) that is privileged. Sudo does not, sudo still acts as the original account which has been given admin level rights.
Here is how you can see it in action...
scott@ntg-scott-lnx-desk:/tmp$ sudo touch test1 scott@ntg-scott-lnx-desk:/tmp$ ll | grep test -rw-rw-r-- 1 scott scott 0 Jul 19 15:34 test0 -rw-rw-r-- 1 scott scott 0 Jul 19 15:34 test1Notice that when I made a file using sudo, it didn't make the file as root or any other account, the action was taken by the same account. Just in one case access to privileges was allowed and in the other case it was protected. But the account itself has the privileges in this case, just administered by the sudo mechanism.
A little test on my Fedora 34
-
@eddiejennings said in sudo problems:
A little test on my Fedora 34
Did you disable the password requirement for sudo? Because by default that is required.
-
@jaredbusch said in sudo problems:
@eddiejennings said in sudo problems:
A little test on my Fedora 34
Did you disable the password requirement for sudo? Because by default that is required.
I did for the
wheelgroup. Below are the results. This thread interests me because I've always seen processes ran using sudo or files made using sudo are run as / owned by root. I was looking through/etc/sudo.confand no setting seemed like it would change this behavior.
-
@jaredbusch said in sudo problems:
@scottalanmiller said in sudo problems:
@pete-s said in sudo problems:
We want to move to using ssh certificates on our servers and remove all passwords.
That's what we do.
Since when? What do you use to manage and generate certificates?
Generate with ssh-keygen. Manage with a wiki. We are only so big, so it works fine.
-
@eddiejennings said in sudo problems:
@scottalanmiller said in sudo problems:
I can prove the degree to which sudo exposes that it is allowing a privileged account to take an action compared to allowing access to a privileged account (which can be argued is the same thing, both are privileges, but sudo is more extreme of the original account being the privileged one.) Older tools, like su allow the user to move from using their own unprivileged account to using root (or something else) that is privileged. Sudo does not, sudo still acts as the original account which has been given admin level rights.
Here is how you can see it in action...
scott@ntg-scott-lnx-desk:/tmp$ sudo touch test1 scott@ntg-scott-lnx-desk:/tmp$ ll | grep test -rw-rw-r-- 1 scott scott 0 Jul 19 15:34 test0 -rw-rw-r-- 1 scott scott 0 Jul 19 15:34 test1Notice that when I made a file using sudo, it didn't make the file as root or any other account, the action was taken by the same account. Just in one case access to privileges was allowed and in the other case it was protected. But the account itself has the privileges in this case, just administered by the sudo mechanism.
A little test on my Fedora 34
That's weird. Why is it one way on Ubuntu and one way on Fedora?
-
@eddiejennings said in sudo problems:
@jaredbusch said in sudo problems:
@eddiejennings said in sudo problems:
A little test on my Fedora 34
Did you disable the password requirement for sudo? Because by default that is required.
I did for the
wheelgroup. Below are the results. This thread interests me because I've always seen processes ran using sudo or files made using sudo are run as / owned by root. I was looking through/etc/sudo.confand no setting seemed like it would change this behavior.Yeah, I use that setting most of the time, too.
-
@scottalanmiller said in sudo problems:
@jaredbusch said in sudo problems:
@scottalanmiller said in sudo problems:
@pete-s said in sudo problems:
We want to move to using ssh certificates on our servers and remove all passwords.
That's what we do.
Since when? What do you use to manage and generate certificates?
Generate with ssh-keygen. Manage with a wiki. We are only so big, so it works fine.
That is not certificates. That is keys. Completely different.
-
@jaredbusch said in sudo problems:
@scottalanmiller said in sudo problems:
@jaredbusch said in sudo problems:
@scottalanmiller said in sudo problems:
@pete-s said in sudo problems:
We want to move to using ssh certificates on our servers and remove all passwords.
That's what we do.
Since when? What do you use to manage and generate certificates?
Generate with ssh-keygen. Manage with a wiki. We are only so big, so it works fine.
That is not certificates. That is keys. Completely different.
I don't know what @scottalanmiller uses but ssh-keygen is used to generate ssh certificates as well.
From the man page:
ssh-keygensupports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8).But if you are automating certificate generation, you need to wrap this in something.
