4 ms·

You can also set up sudo so that it does not require your password for certain commands, that does not mean you are not still getting root to do a thing that re

by yebyen 9y ago

You can also set up sudo so that it does not require your password for certain commands, that does not mean you are not still getting root to do a thing that requires root permissions. It sounds like it has been made relatively "safer" but, the comment you linked says that it's the author's opinion it is a bad idea, because the user is doing something they are not allowed to undo. So you are getting root access, via policy. Why do you need root access when you could just write the package contents out to a directory you control, and run them without any signatures or policy? (Or even with verifying signatures, why not I guess...) I'm not asking you personally for a position on this, I'm just explaining how it's different... you are still taking root, only through a safety wrapper. The advantages to this that I can see are 1) the user is encouraged to install signed packages, and 2) the sysadmin is empowered to keep the user's installed packages up-to-date. Those are maybe compelling, but I don't see major advantages. Give me something like rvm+bundler and I'll be a lot happier. (I don't really want sysadmin to have powers to do things that I can't undo, either!)

jhasse 9y ago
> You can also set up sudo so that it does not require your password for certain commands, that does not mean you are not still getting root to do a thing that requires root permissions. The difference is, that this is configured by default on Fedora. > Why do you need root access when you could just write the package contents out to a directory you control, and run them without any signatures or policy? Because applications have their paths hard-coded all over the place. Also some packages (e. g. webservers running on port 80) wouldn't work without root anyway.
- yebyen 9y ago
  "By default" is just not very convincing for me. I know that RedHat has some very qualified people working for them, but the user is getting root and doing root things, regardless of whether or not they enter their password, or if the distro has deigned that it's OK. RedHat has some very peculiar ideas about security, and I'm not saying that in a bad way. Someone decided that this was OK. In the same way, OpenShift (another RedHat product, their Kubernetes distro) decided that it was unsafe to allow users with "project admin" rights to create a DaemonSet within their own project. After reading their position, I have to say I agree (DaemonSets run with a higher priority than ReplicaSet, so a malicious user could use their Project Admin privileges to swamp an entire cluster, preventing other pods from running. You need the Cluster Admin role for this.) The fact this is configured by default, does not mean much to me. If you trust Fedora to review every package for security vulnerabilities before it is signed and released, that's fine! You should, if you are using their distribution. My InfoSec group does not grant root privileges to non-root users without a good reason, and I am certain even explained properly, they would balk and groan about this policy. It is a potential avenue for privilege escalation, and the only reason it could be safe is because of the vigilance of Fedora team. That's convenient, but not very "belt and suspenders" in my opinion. > applications have their paths hard-coded all over the place This is open-source, if an application has a hard-coded path, it can be fixed. If it isn't open-source, I'd assume RH won't sign the packages. Good software remains portable by making these things configurable in a .conf or environment variable (and good upstream dev teams will accept patches to make their software more portable). That is surely a problem as you have highlighted and good software shouldn't have hard-coded paths all over the place without reason. So we shouldn't optimize for that case. > Also some packages (e. g. webservers running on port 80) wouldn't work without root anyway. That is by design, that is why those are called privileged ports (<1024.) Maybe it is inconvenient, but how does allowing the user to install a web server as root and start listening on port 80, improve any part of this particular user story? What exactly is your user going to do with a running web server listening on Port 80 when they still need to be added to httpd group (by root) or they can't write to /var/www, and what's the point of letting them install the package when they still can't make adjustments to /etc/httpd.conf without root access?
  - jhasse 9y ago
    > but the user is getting root No, he's not. > My InfoSec group does not grant root privileges to non-root users without a good reason This doesn't either. > This is open-source, if an application has a hard-coded path, it can be fixed. If it isn't open-source, I'd assume RH won't sign the packages. Good software remains portable by making these things configurable in a .conf or environment variable (and good upstream dev teams will accept patches to make their software more portable). > That is surely a problem as you have highlighted and good software shouldn't have hard-coded paths all over the place without reason. So we shouldn't optimize for that case. I agree, but I guess it's a lot of work and that's why no one has done it yet.
    - yebyen 9y ago
      > but the user is getting root > No, he's not. https://isc.sans.edu/forums/diary/Is+the+polkit+Grinch+Going+to+Steal+your+Christmas/19077/ https://isc.sans.edu/forums/diary/Is+the+polkit+Grinch+Going... """ Polkit works differently then sudo. With sudo, I configure which software a user is allowed to run as root (or another user). With polkit, I configure which privileges a user is allowed to take advantage of while running a particular piece of software. The problem pointed out by Alert Logic is two fold. First of all, the default polkit configuration on many Unix systems (e.g. Ubuntu), does not require authentication. Secondly, the polkit configuration essentially just maps the "wheels" group, which is commonly used for sudo users, to the polkit "Admin". This gives users in the "wheel" group access to administrative functions, like installing packages, without having to enter a password. The main risk is privilege escalation. With sudo, an attacker would have to enter the user's password after compromising a lesser user account in the wheel group. With polkit, all it takes is to install a package using the polkit tool "pkcon", which takes advantage of the loose polkit configuration to install packages. """ This is from 2014. What has changed since then? Maybe saying "the user gets root" is hyperbole, but the user gains a set of privileges to use in pkcon, via polkit, that they would not normally have. That is the definition of privilege escalation. It's just that in this case, it's hopefully done safely, and so "privilege escalation" does not necessarily carry the connotation of "security vulnerability." It's only one step away: a vulnerability is discovered in pkcon, and now it is an actual security vulnerability. But you have some bridges to cross before you convince me that it is safe. My Debian systems don't have an equivalent route for users to escalate their privileges when they haven't been granted them explicitly by a system admin. Edit: and here's a thread from 2009, when this was already the case https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/424IY7COGMWSYGLGUAD56KKHCCHLWRMS/ https://lists.fedoraproject.org/archives/list/devel@lists.fe... > It certainly seems like an easy path to a denial of service: just install everything and run the machine out of disk space. So, it is already potentially unsafe for the very same reason that my earlier example, DaemonSet, is unsafe for mere project admin! It presents a clear path to DoS for users on any system that is remotely short on disk. > I agree, but I guess it's a lot of work and that's why no one has done it yet. If you think that configuring PolKit and SELinux properly for every system that needs to go outside of the policies that RH considers to be sane default, is not a lot of work... I can't really provide an example from inside of the last 10 years to refute that. The RedHat mark has literally saved me from doing convenient-but-unsafe things at least dozens of times, this seems out of character for them. But it's been policy since at least 2009, and I haven't heard of it being used in any major breaches, so maybe it's actually not so bad.

by yebyen 9y ago

jhasse 9y ago

> You can also set up sudo so that it does not require your password for certain commands, that does not mean you are not still getting root to do a thing that requires root permissions. The difference is, that this is configured by default on Fedora. > Why do you need root access when you could just write the package contents out to a directory you control, and run them without any signatures or policy? Because applications have their paths hard-coded all over the place. Also some packages (e. g. webservers running on port 80) wouldn't work without root anyway.

yebyen 9y ago
"By default" is just not very convincing for me. I know that RedHat has some very qualified people working for them, but the user is getting root and doing root things, regardless of whether or not they enter their password, or if the distro has deigned that it's OK. RedHat has some very peculiar ideas about security, and I'm not saying that in a bad way. Someone decided that this was OK. In the same way, OpenShift (another RedHat product, their Kubernetes distro) decided that it was unsafe to allow users with "project admin" rights to create a DaemonSet within their own project. After reading their position, I have to say I agree (DaemonSets run with a higher priority than ReplicaSet, so a malicious user could use their Project Admin privileges to swamp an entire cluster, preventing other pods from running. You need the Cluster Admin role for this.) The fact this is configured by default, does not mean much to me. If you trust Fedora to review every package for security vulnerabilities before it is signed and released, that's fine! You should, if you are using their distribution. My InfoSec group does not grant root privileges to non-root users without a good reason, and I am certain even explained properly, they would balk and groan about this policy. It is a potential avenue for privilege escalation, and the only reason it could be safe is because of the vigilance of Fedora team. That's convenient, but not very "belt and suspenders" in my opinion. > applications have their paths hard-coded all over the place This is open-source, if an application has a hard-coded path, it can be fixed. If it isn't open-source, I'd assume RH won't sign the packages. Good software remains portable by making these things configurable in a .conf or environment variable (and good upstream dev teams will accept patches to make their software more portable). That is surely a problem as you have highlighted and good software shouldn't have hard-coded paths all over the place without reason. So we shouldn't optimize for that case. > Also some packages (e. g. webservers running on port 80) wouldn't work without root anyway. That is by design, that is why those are called privileged ports (<1024.) Maybe it is inconvenient, but how does allowing the user to install a web server as root and start listening on port 80, improve any part of this particular user story? What exactly is your user going to do with a running web server listening on Port 80 when they still need to be added to httpd group (by root) or they can't write to /var/www, and what's the point of letting them install the package when they still can't make adjustments to /etc/httpd.conf without root access?
- jhasse 9y ago
  > but the user is getting root No, he's not. > My InfoSec group does not grant root privileges to non-root users without a good reason This doesn't either. > This is open-source, if an application has a hard-coded path, it can be fixed. If it isn't open-source, I'd assume RH won't sign the packages. Good software remains portable by making these things configurable in a .conf or environment variable (and good upstream dev teams will accept patches to make their software more portable). > That is surely a problem as you have highlighted and good software shouldn't have hard-coded paths all over the place without reason. So we shouldn't optimize for that case. I agree, but I guess it's a lot of work and that's why no one has done it yet.
  - yebyen 9y ago
    > but the user is getting root > No, he's not. https://isc.sans.edu/forums/diary/Is+the+polkit+Grinch+Going+to+Steal+your+Christmas/19077/ https://isc.sans.edu/forums/diary/Is+the+polkit+Grinch+Going... """ Polkit works differently then sudo. With sudo, I configure which software a user is allowed to run as root (or another user). With polkit, I configure which privileges a user is allowed to take advantage of while running a particular piece of software. The problem pointed out by Alert Logic is two fold. First of all, the default polkit configuration on many Unix systems (e.g. Ubuntu), does not require authentication. Secondly, the polkit configuration essentially just maps the "wheels" group, which is commonly used for sudo users, to the polkit "Admin". This gives users in the "wheel" group access to administrative functions, like installing packages, without having to enter a password. The main risk is privilege escalation. With sudo, an attacker would have to enter the user's password after compromising a lesser user account in the wheel group. With polkit, all it takes is to install a package using the polkit tool "pkcon", which takes advantage of the loose polkit configuration to install packages. """ This is from 2014. What has changed since then? Maybe saying "the user gets root" is hyperbole, but the user gains a set of privileges to use in pkcon, via polkit, that they would not normally have. That is the definition of privilege escalation. It's just that in this case, it's hopefully done safely, and so "privilege escalation" does not necessarily carry the connotation of "security vulnerability." It's only one step away: a vulnerability is discovered in pkcon, and now it is an actual security vulnerability. But you have some bridges to cross before you convince me that it is safe. My Debian systems don't have an equivalent route for users to escalate their privileges when they haven't been granted them explicitly by a system admin. Edit: and here's a thread from 2009, when this was already the case https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/424IY7COGMWSYGLGUAD56KKHCCHLWRMS/ https://lists.fedoraproject.org/archives/list/devel@lists.fe... > It certainly seems like an easy path to a denial of service: just install everything and run the machine out of disk space. So, it is already potentially unsafe for the very same reason that my earlier example, DaemonSet, is unsafe for mere project admin! It presents a clear path to DoS for users on any system that is remotely short on disk. > I agree, but I guess it's a lot of work and that's why no one has done it yet. If you think that configuring PolKit and SELinux properly for every system that needs to go outside of the policies that RH considers to be sane default, is not a lot of work... I can't really provide an example from inside of the last 10 years to refute that. The RedHat mark has literally saved me from doing convenient-but-unsafe things at least dozens of times, this seems out of character for them. But it's been policy since at least 2009, and I haven't heard of it being used in any major breaches, so maybe it's actually not so bad.