Originally posted by markg85
View Post
Announcement
Collapse
No announcement yet.
KDE Ends 2021 With More Plasma Wayland Fixes, Root File Operations For Dolphin
Collapse
X
-
- Likes 1
-
-
Originally posted by markg85 View PostThere was a time, years ago, when "security paranoid people" discovered ways to abuse KDE's applications with elevated permissions. In that time the security minded folks in KDE-land kinda decided that running anything as root is a no-go and should be forbidden. Hence patches were made to forbid Plasma to be run as root, forbid dolphin and i believe a few other applications too. In the beginning this was as strict as only users, later this got relaxed - at least in dolphin - in various changes throughout the years.
Kali Linux a security distribution made all the same kind of arguments you did about being only a single user running as root would be fine. Yes they found for wifi attacks and so on running with root capabilities was faster but they also found when it goes wrong the stuff goes wrong in a big way.
Running kodi as root with all capabilities (privileges) and something goes wrong instead of being a simple restart the system fix as it would have been as a normal user its a complete reinstall possible with complete data loss. Yes the power of the root granted .
https://securityboulevard.com/2020/0...-on-kali-2020/ Yes it took them until 2020 to change it. Of course you still have users forcing their way back as running as root and not understanding the level of danger they are playing with.
The hard reality is running any more than you need to as root is not a good idea and will cause you trouble at some point or another.
Originally posted by markg85 View PostNow what if you play with a single board computer where you intent to have only one application running? Say kodi as media center?
In that case, and i've been there, it can be very handy to start X and open something else. Could be for copying stuff, could be for editing config files could be just to see how Plasma would work in that environment.
You will find something dangerous when you are running with
CAP_SYS_ADMIN
Don't choose CAP_SYS_ADMIN if you can possibly avoid it! A vast proportion of existing capability checks are associated with this capability (see the partial list above). It can plausibly be called "the new root", since on the one hand, it confers a wide range of powers, and on the other hand, its broad scope means that this is the capability that is required by many privileged programs. Don't make the problem worse. The only new features that should be associated with CAP_SYS_ADMIN are ones that closely match existing uses in that silo.
The fault has been seen for over 20 years now. The problem is security related and it does not require multi users as such because the Linux kernel behaves different between a normal user account/non capability process and a root/capability granted process..
Linux root for capabilities granted is closest user on MS Windows user is SYSTEM. Do note under windows you normally cannot log in as system. Yes administrator account under windows are not the most privileged account you can see it at times when there are in use files that windows administrator account cannot delete but if you are running as windows SYSTEM user or using a tool running a bit as Windows SYSTEM user you can. Yes at time when stuff goes wrong with a process running windows system user it can be a reinstall as well.
Like it or not users running applications normally don't need the full rights to-do everything. That everything is ultra broad and has many downsides.
Early Late 1990s early 2000 it was found running graphical applications as root/privilege capabilities resulted in different behavour on Linux and early 2000 it was found that this different behavour could have adverse effects. Yes this reality people keep on wanting to ignore.
- Likes 1
Comment
-
Originally posted by Termy View Posti mean if you don't have viewing permission to directories - or is that covered?
We still have to get it out in production yet and see if they have got it exactly right. If it right you will be able to access directories you normally cannot.
Yes gnome does it by GVFS not KIO. So it spread out under all gnome applications with GVFS so gedit can use admin:/// paths and so on. It will be interesting to see how KIO handles it because this will mean kate and so on will be able todo it.
Yes it would be insane to edit a system file in LibreOffice writer but these kinds of things will come possible.
The KIO polkit changes should allow every operation you could do while running dolphin/kate... as root in the past is possible while running the graphical parts of dolphin/kate... as normal user with privilege dbus service doing the operations requiring privilege once allowed by polkit. This also explains why this has not been a fast or simple process. There is a massive number of features that must work perfectly.
- Likes 1
Comment
-
Originally posted by aufkrawall View PostThe efforts were going on for years though and you can read some disputes in the KIO MR.
Despite of the concerns, I'm still glad it has landed. I wouldn't have disallowed Dolphin from running as root before this even was implemented. I don't want to be put in shackles just because other people would torch their own houses otherwise. Really not my concern.
Disallowing sudo and so on got users upset on one hand. Running as root could possible result in complete file system corruption yes the extra capabilities granted to root are quite scary. Distributions started in the late1990s early 2000 moving away from providing a graphical root user login due to the issues started appearing.. We are not talking minor issues either like the system is more likely to totally freeze up if you are running graphical as root capabilities than when you are not.
Yes the work to get X.org to work as normal user is part of the same effort.
Being blamed for being in the way and not allowing user to do what they want is better than being blamed for the user having total data loss due to a defect you knew about.
Really its annoying that its taken over 20 years to start to getting these problems fixed properly.
Of course we still have items like SDDM that need to get to the point they can use a non root X11 server/wayland output.
There is quite a long road it fixing all these issues up.Last edited by oiaohm; 01 January 2022, 06:20 PM.
Comment
-
Originally posted by oiaohm View Post
The answer is no Linus video did not change anything about the speed. Security of stuff like this takes while.
In reality the core complaint that Linus had is correct, which is that from a purely non advanced user experience point of view the situation was terrible and telling people to "use a CLI instead" completely misses the point.
If the Linus video wasn't made then it may have taken another couple or so years to push that final 20% to get it out.
- Likes 3
Comment
-
Originally posted by oiaohm View Post
This shows something that you never understood the problem.
Kali Linux a security distribution made all the same kind of arguments you did about being only a single user running as root would be fine. Yes they found for wifi attacks and so on running with root capabilities was faster but they also found when it goes wrong the stuff goes wrong in a big way.
Running kodi as root with all capabilities (privileges) and something goes wrong instead of being a simple restart the system fix as it would have been as a normal user its a complete reinstall possible with complete data loss. Yes the power of the root granted .
What you say there can also happen as a user.
The only reason (i can think of) that would justify running it as a user is to make it more fool proof. That as a reason would be acceptable as it makes it easier for tech savvy users to run such an application. As root you might need to get warnings about that. Let the user know that it's not the advised way etc... but not forbid it.
Originally posted by oiaohm View Posthttps://securityboulevard.com/2020/0...-on-kali-2020/ Yes it took them until 2020 to change it. Of course you still have users forcing their way back as running as root and not understanding the level of danger they are playing with.
The hard reality is running any more than you need to as root is not a good idea and will cause you trouble at some point or another.
do take a look at capabilities some time.
You will find something dangerous when you are running with
Yes CAP_SYS_ADMIN is the privilege we really do align with root operations and do note the nightmare here is not properly defined. Problem is this alters even how the OOM Killer responds to the application. and what memory and disc space you are allowed to allocate. Yes allowed to allocate without the normal safe guards so you could be forcing the kernel to suspend kernel processes that should be happening your process to proceed that would have just shared processing time and proceed in background if you were not with CAP_SYS_ADMIN..
The fault has been seen for over 20 years now. The problem is security related and it does not require multi users as such because the Linux kernel behaves different between a normal user account/non capability process and a root/capability granted process..
Linux root for capabilities granted is closest user on MS Windows user is SYSTEM. Do note under windows you normally cannot log in as system. Yes administrator account under windows are not the most privileged account you can see it at times when there are in use files that windows administrator account cannot delete but if you are running as windows SYSTEM user or using a tool running a bit as Windows SYSTEM user you can. Yes at time when stuff goes wrong with a process running windows system user it can be a reinstall as well.
Like it or not users running applications normally don't need the full rights to-do everything. That everything is ultra broad and has many downsides.
Early Late 1990s early 2000 it was found running graphical applications as root/privilege capabilities resulted in different behavour on Linux and early 2000 it was found that this different behavour could have adverse effects. Yes this reality people keep on wanting to ignore.
I surely don't vividly remember the exact details.
The problem i have with this paranoid security that happened back then was the urge to immediately fix it while it was very much an edge case and not that likely to be widely exploited. A fix (with polkit) was known back then too but the whole stack wasn't ready for it. Hence it taking so long till it finally landed.
The proper way would have been to leave it "broken" and inform the users that it's not advices to run it as root. Then get working on the proper fix to transition from one mechanism to the other. Not to bluntly nuke the root route (now only the sudo route) and stay in that state for years till the polkit route has gotten enough support.
There's also a lot of blame to place on the security folks here too. Fine if they do research and find holes. They do often also point out where that hole is and what a fix could be. Thus far they did a fine job. But it stopped right there. The solution was to nuke a feature. Not to properly explain how the hole could be dangerous. Not to poke the right people (polkit ones) to let them know that a proper fix would be to get polkit widely adopted. And yes, i do expect the security researchers to do that! They put in the time to find holes, let others fix their findings then also put in the effort to at least make the fix as minimally invasive as possible. Aka, NOT to nuke a feature but to get it working without the issue persisting.
Granted, i've only very rarely been in the position where i actually needed a graphical Dolpin ever since it became impossible to run as sudo. I think only once or twice.
Comment
-
-
Originally posted by mdedetrich View PostI think its ridiculously naive to claim that Linus's video had no impact. Yes the work has been ongoing but the amount of traction that Linus brings put that specific issue higher on the priority list and this was even admitted by KDE developers on reddit in response to his video.
In reality the core complaint that Linus had is correct, which is that from a purely non advanced user experience point of view the situation was terrible and telling people to "use a CLI instead" completely misses the point.
If the Linus video wasn't made then it may have taken another couple or so years to push that final 20% to get it out.
Yes Linus tech tip videos had effects and they were not all positive. Like the recent merge due to Linus tech tip video caused spam is 4 weeks behind because the merge review request got lost in spam. So yes KDE developers are fairly media aware. Yes the post on reddit was more about stopping a disaster of operation disruptions that if it was not brought under control was going to push the late KIO polkit feature even latter. The reality there was no where high to go on the priority list than where KIO polkit was before Linus tech tips made their videos.
KIO polkit is need on the Wayland side and on the user mode only x.org X11 server as it does not accept connections from different user out box. This problem was detailed in 2019. Getting it working right has been the major problem.
There are still over 100 known code quality faults to fix in the KIO polkit code to fix yet. Hopefully none of them are deal breakers.
Comment
Comment