Luigi Toscano wrote:
The user need to provide a password to access the privileged files,
the only operation allowed will be the requested one against that file.
Running an entire application as root expose all the possible operations:
I understand the argument, I just don't agree that it makes sense.
Upstream's point is that this opens up a privilege escalation possibility
for malicious code running under your account. But let me point out that:
1. if you have malicious code running under your account to begin with, you
have already lost. The malware can already read, encrypt and/or wipe all
your personal data, which is the really important one (not the system files
owned by root), it does not need ANY privilege escalation exploit for that.
2. if you are in a root session, the malicious code is already running as
root and so there is no privilege escalation vulnerability at all. Yet, the
check also prevents running the application in that context.
3. the privilege escalation is only possible if the user already voluntarily
started the application as root and took the risk. The mere fact of allowing
it is NOT a vulnerability. Therefore, consider the 2 cases:
3a) The user does not want or need to run the application as root. Then the
change will not have ANY impact on the user. There is NO security issue
3b) The user wants or needs to run the application as root. Then the change
breaks the application for the user!
4. by refusing to run as root, you just make the user run another
application without such a check instead, which has the exact same issue.
Users will NOT use sudoedit or KAuth or whatever upstream wants to force
them to use. So what security benefit does this change really bring?
In the end, this only removes power from the user and brings no practical
security benefit whatsoever. Free Software is not about having the computer
dictate what the user can do!