> 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.
> 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.
>There are other services running which create files as root on other distros
Did the user affect the system to create those files?
Assume the user can't install packages, then they can't create these files. (Maybe they can flood them, by sending bad packets, but they don't create them. If a file is created in root's name, because of user activity, then I'd guess the user must have run some setuid program.)
If admin doesn't install some setuid program (or say, an ssh server), there won't be any root-owned file created containing a log of authentication rejects from the ssh server for the user to flood with error messages by sending bad packets.
Maybe the user did cause these files to expand, for example if they are access logs... but generally the only user access activities that are logged are those that are enabled somehow by the system admin.
What user process is creating files in /tmp owned by the root user? X11? Explained by setuid bit, and hardly ever anymore as the user is not responsible for starting gdm.
All I'm saying is, it is against the principle of least surprise for this pkcon to be the default configuration.
Is it true that users need to be in the "wheel" group for this configuration to affect them by default? If so, I withdraw my position. This is an obscure fact that I learned a long time ago, and everyone else should know (I gest) that "wheel" users are administrative users and they will be given opportunities to escalate their permissions (via sudo, or otherwise.)
If you are creating users in the wheel group and you don't know what that means, it's your fault when they get access you didn't mean to give them. If this policy applies to any local user regardless of wheel, then I guess my position stands.
Your argument is that users should know how the system works; I'm saying this system is different than others I've adminned.
If I read the manual in its entirety, then yes, I will know all of the quirks of the system. That's true. Naïvely though, I might have thought as a sysadmin that by configuring a disk quota, I had effectively put an actual cap on how much disk a user could consume.
I would be wrong, surprisingly! (It is surprising, if you haven't just finished having this conversation.) That is a violation of the principle of least surprise.
Please take a look at the nine section treatise on disk quotas from the RHEL7 manual:
Notice the conspicuous absence of any mention of polkit or pkcon? That is because nobody would think the system provides a way for unprivileged users to affect it in a substantial way that circumvents their disk quotas. They're not obviously related, so it is surprising that a default policy makes them related. (I'm not talking about methods that the users can maybe cause a flood in some logs, because log rotation is usually configured by default.)
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.