5 ms·

> 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.ed

by 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.

jhasse 9y ago
> 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. But they HAVE this privilege (installing packages) normally in Fedora, so it isn't privilege escalation. > just install everything and run the machine out of disk space. Or just create large empty files??
- yebyen 9y ago
  > But they HAVE this privilege (installing packages) normally in Fedora, so it isn't privilege escalation. They don't have permission to write files as root without the help of polkit and pkcon. They can write files as root with the polkit policy's help. Broadly, or not... intentionally, or not! As an outsider coming from another distro, I would argue that policy does not follow the "principle of least surprise." Maybe long-time RH users are already not surprised, it looks like this is in no way a recent change. > Or just create large empty files?? If you set up sensible per-user disk quotas, you will prevent this. But if the user can write new files to the disk that are owned by root via polkit, then that would enable them to circumvent your per-user disk quotas. They will not own the files that pkcon writes via polkit. (For a second I was going to suggest it would be worse if they did own the file, because of setuid bits... but then I remembered where this conversation started, and what side of this debate I'm supposed to be on. ;) Also a setuid bit on a file that you own would only enable you to escalate your privileges to... yourself. I'm sure any packages that have setuid bits are at the top of Fedora's security audit list, though... if you installed a package that installs a binary with setuid bits, that's another possible avenue for privilege escalation vulnerability that you did not have before PolKit opened the window for you.
  - jhasse 9y ago
    > They don't have permission to write files as root without the help of polkit and pkcon. They can write files as root with the polkit policy's help. Broadly, or not... intentionally, or not! As an outsider coming from another distro, I would argue that policy does not follow the "principle of least surprise." There are other services running which create files as root on other distros, too. Have a look in /tmp for example. > If you set up sensible per-user disk quotas, you will prevent this. If you are able to set-up per-user disk quotas, you're able to also change the policy.

by yebyen 9y ago

jhasse 9y ago

> 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. But they HAVE this privilege (installing packages) normally in Fedora, so it isn't privilege escalation. > just install everything and run the machine out of disk space. Or just create large empty files??

yebyen 9y ago
> But they HAVE this privilege (installing packages) normally in Fedora, so it isn't privilege escalation. They don't have permission to write files as root without the help of polkit and pkcon. They can write files as root with the polkit policy's help. Broadly, or not... intentionally, or not! As an outsider coming from another distro, I would argue that policy does not follow the "principle of least surprise." Maybe long-time RH users are already not surprised, it looks like this is in no way a recent change. > Or just create large empty files?? If you set up sensible per-user disk quotas, you will prevent this. But if the user can write new files to the disk that are owned by root via polkit, then that would enable them to circumvent your per-user disk quotas. They will not own the files that pkcon writes via polkit. (For a second I was going to suggest it would be worse if they did own the file, because of setuid bits... but then I remembered where this conversation started, and what side of this debate I'm supposed to be on. ;) Also a setuid bit on a file that you own would only enable you to escalate your privileges to... yourself. I'm sure any packages that have setuid bits are at the top of Fedora's security audit list, though... if you installed a package that installs a binary with setuid bits, that's another possible avenue for privilege escalation vulnerability that you did not have before PolKit opened the window for you.
- jhasse 9y ago
  > They don't have permission to write files as root without the help of polkit and pkcon. They can write files as root with the polkit policy's help. Broadly, or not... intentionally, or not! As an outsider coming from another distro, I would argue that policy does not follow the "principle of least surprise." There are other services running which create files as root on other distros, too. Have a look in /tmp for example. > If you set up sensible per-user disk quotas, you will prevent this. If you are able to set-up per-user disk quotas, you're able to also change the policy.