Bug#894772: RFS: deepin-system-monitor/1.4.3-1 [ITP]
On Mon 04/09 14:02, Adam Borowski wrote: > On Mon, Apr 09, 2018 at 05:29:14PM +0800, Yanhao Mo wrote: > > Hi, Adam > > Very thanks for checking my package and pointing these issues. > > I have communicate with upstream author of deepin-system-monitor, and he > > confirmed these security problems. As a result, he is willing to modify > > d-s-m sources to limited the privilege operations within a very small > > helper program with some capabilities, at the same time he > > will refactor gui program of d-s-m to perform these operations by > > sending request to the helper program via dubs. The helper program will > > refuse any other request which is not sent from d-s-m. > > You might want to ask someone with a clue about policykit/etc for advice. I > don't currently even know where to look. > > > I hope this will fix these issues. And that will take some times. So > > let's wait. > > There's no hurry -- Ubuntu is long since frozen, Debian won't freeze until > November or December. > > But, you might want to just drop the caps: a system monitor that can kill > only your own processes is pretty useful; this is what all other similar > tools do. Elevating to kill others might be useful but is not the primary > feature I'd expect from such a program. > > Obviously, this is moot if you prefer to wait for the full fix. > > > For the nethogs part, the situation is: d-m-s need a library from > > it, but the nethogs maintainer of debian doesn't package libnethogs > > separately, we(pkg-deepin team) have already request for that [1], but > > got no reply. So I decided to use the nethogs sources within upstream > > d-m-s source tree directly to build d-m-s. Maybe this is a bad idea? > > Maybe it's better to take a nmu upload for nethogs? Some advice is > > very appreciated. > > Looking at the maintainer's QA page: > https://qa.debian.org/developer.php?email=kretcheu%40gmail.com > I see he's not very active but nowhere close to being gone (did three > uploads of other packages this year). It's likely he saw the request but > couldn't act on it immediately -- what about pinging him if that's the case? > Also, most people are a lot more willing to accept a patch compared to being > told to do the work themselves. > > > > d-s-m crashed for me twice (segfault) while casually perusing it, > > As for this. The upstream author says It's very sorry for the insufficient > > testing. He will try his best to find why and fix it. > > It seems both of these segfaults happened while shutting down the program. > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢰⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC? > ⠈⠳⣄ I will try to communicate more with the upstream author several times, to help him to believe policykit is a better solution before he start to refactor the code. During this time, I will prepare a patch set and send to nethogs maintainer to try to solve the libnethogs problem. Thanks the advice about this :) . -- Yanhao Mo signature.asc Description: PGP signature
Bug#894772: RFS: deepin-system-monitor/1.4.3-1 [ITP]
On Mon, Apr 09, 2018 at 05:29:14PM +0800, Yanhao Mo wrote: > Hi, Adam > Very thanks for checking my package and pointing these issues. > I have communicate with upstream author of deepin-system-monitor, and he > confirmed these security problems. As a result, he is willing to modify > d-s-m sources to limited the privilege operations within a very small > helper program with some capabilities, at the same time he > will refactor gui program of d-s-m to perform these operations by > sending request to the helper program via dubs. The helper program will > refuse any other request which is not sent from d-s-m. You might want to ask someone with a clue about policykit/etc for advice. I don't currently even know where to look. > I hope this will fix these issues. And that will take some times. So > let's wait. There's no hurry -- Ubuntu is long since frozen, Debian won't freeze until November or December. But, you might want to just drop the caps: a system monitor that can kill only your own processes is pretty useful; this is what all other similar tools do. Elevating to kill others might be useful but is not the primary feature I'd expect from such a program. Obviously, this is moot if you prefer to wait for the full fix. > For the nethogs part, the situation is: d-m-s need a library from > it, but the nethogs maintainer of debian doesn't package libnethogs > separately, we(pkg-deepin team) have already request for that [1], but > got no reply. So I decided to use the nethogs sources within upstream > d-m-s source tree directly to build d-m-s. Maybe this is a bad idea? > Maybe it's better to take a nmu upload for nethogs? Some advice is > very appreciated. Looking at the maintainer's QA page: https://qa.debian.org/developer.php?email=kretcheu%40gmail.com I see he's not very active but nowhere close to being gone (did three uploads of other packages this year). It's likely he saw the request but couldn't act on it immediately -- what about pinging him if that's the case? Also, most people are a lot more willing to accept a patch compared to being told to do the work themselves. > > d-s-m crashed for me twice (segfault) while casually perusing it, > As for this. The upstream author says It's very sorry for the insufficient > testing. He will try his best to find why and fix it. It seems both of these segfaults happened while shutting down the program. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC? ⠈⠳⣄
Bug#894772: [yanha...@gmail.com: Re: Bug#894772: RFS: deepin-system-monitor/1.4.3-1 [ITP]]
- Forwarded message from Yanhao Mo <yanha...@gmail.com> - Date: Mon, 9 Apr 2018 17:29:14 +0800 From: Yanhao Mo <yanha...@gmail.com> To: Adam Borowski <kilob...@angband.pl> Subject: Re: Bug#894772: RFS: deepin-system-monitor/1.4.3-1 [ITP] User-Agent: Mutt/1.9.4 (2018-02-28) On Sun 04/08 21:55, Adam Borowski wrote: > Hi! > As for the packaging itself, the nethogs/ subproject is not included in the > copyright file; it seems to be already packaged separately, too. > > But, that's easy to fix. I found a bigger problem though: > > The program has a long list of caps (with a fallback to setuid), that allow > any user perform most of root-only actions. For example one of menus allows > anyone to kill/suspend/resume any process in the system. No authentication > of any kind, no policy, just kill any process, period. > > It's not just the GUI user who can do this, it's easy enough to simulate a > GUI to have deepin-system-monitor do what any process, by any uid, wants. > > And if you say "most computers don't have untrusted users", then well -- you > still don't want some random thing running as another uid to have full > control over the system. And, most schools/etc will install a bunch of > available desktop environments so individual users can choose; if Deepin is > one of these environments, you can take over anyone else. > > And even if deepin-system-monitor had appropriate access control, it's still > a thoroughly bad idea to grant caps to a GUI process. d-s-m crashed for me > twice (segfault) while casually perusing it, I imagine it'd be trivial to do > so intentionally. And even if your code is 100% perfectly correct and > solid, d-s-m uses many many libraries, any of which can have bugs that can > be easy to subvert; various plugins can be loaded into the process, etc. > There's no way this could be done securely: thus, the security boundary must > be elsewhere. Be it a small helper program, some kind of RPC, etc -- the > privileged action can't be done by the GUI program. > > Thus, I'm afraid that deepin-system-monitor can't go into Debian without > some serious rethinking. I cannot adequately assist you here, as I don't > know the way such policies are done these days, you'd need to ask someone > more knowledgeable than me. > > I seriously hope I'm failing to understand something here... Hi, Adam Very thanks for checking my package and pointing these issues. I have communicate with upstream author of deepin-system-monitor, and he confirmed these security problems. As a result, he is willing to modify d-s-m sources to limited the privilege operations within a very small helper program with some capabilities, at the same time he will refactor gui program of d-s-m to perform these operations by sending request to the helper program via dubs. The helper program will refuse any other request which is not sent from d-s-m. I hope this will fix these issues. And that will take some times. So let's wait. For the nethogs part, the situation is: d-m-s need a library from it, but the nethogs maintainer of debian doesn't package libnethogs separately, we(pkg-deepin team) have already request for that [1], but got no reply. So I decided to use the nethogs sources within upstream d-m-s source tree directly to build d-m-s. Maybe this is a bad idea? Maybe it's better to take a nmu upload for nethogs? Some advice is very appreciated. > d-s-m crashed for me twice (segfault) while casually perusing it, As for this. The upstream author says It's very sorry for the insufficient testing. He will try his best to find why and fix it. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893715 regards, -- Yanhao Mo - End forwarded message - Forward message. Sorry for forgetting to cc 894...@bugs.debian.org and pkg-deepin-de...@lists.alioth.debian.org . -- Yanhao Mo signature.asc Description: PGP signature
Bug#894772: RFS: deepin-system-monitor/1.4.3-1 [ITP]
On Wed, Apr 04, 2018 at 01:00:30PM +0800, Yanhao Mo wrote: > * Package name: deepin-system-monitor > Version : 1.4.3-1 > deepin-system-monitor - System monitor for Deepin Desktop Environment Hi! As for the packaging itself, the nethogs/ subproject is not included in the copyright file; it seems to be already packaged separately, too. But, that's easy to fix. I found a bigger problem though: The program has a long list of caps (with a fallback to setuid), that allow any user perform most of root-only actions. For example one of menus allows anyone to kill/suspend/resume any process in the system. No authentication of any kind, no policy, just kill any process, period. It's not just the GUI user who can do this, it's easy enough to simulate a GUI to have deepin-system-monitor do what any process, by any uid, wants. And if you say "most computers don't have untrusted users", then well -- you still don't want some random thing running as another uid to have full control over the system. And, most schools/etc will install a bunch of available desktop environments so individual users can choose; if Deepin is one of these environments, you can take over anyone else. And even if deepin-system-monitor had appropriate access control, it's still a thoroughly bad idea to grant caps to a GUI process. d-s-m crashed for me twice (segfault) while casually perusing it, I imagine it'd be trivial to do so intentionally. And even if your code is 100% perfectly correct and solid, d-s-m uses many many libraries, any of which can have bugs that can be easy to subvert; various plugins can be loaded into the process, etc. There's no way this could be done securely: thus, the security boundary must be elsewhere. Be it a small helper program, some kind of RPC, etc -- the privileged action can't be done by the GUI program. Thus, I'm afraid that deepin-system-monitor can't go into Debian without some serious rethinking. I cannot adequately assist you here, as I don't know the way such policies are done these days, you'd need to ask someone more knowledgeable than me. I seriously hope I'm failing to understand something here... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC? ⠈⠳⣄
Bug#894772: RFS: deepin-system-monitor/1.4.3-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "deepin-system-monitor" * Package name: deepin-system-monitor Version : 1.4.3-1 Upstream Author : Deepin Technology Co., Ltd * URL : https://github.com/linuxdeepin/deepin-system-monitor * License : GPL-3+ Section : utils It builds those binary packages: deepin-system-monitor - System monitor for Deepin Desktop Environment To access further information about this package, please visit the following URL: https://mentors.debian.net/package/deepin-system-monitor Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/deepin-system-monitor/deepin-system-monitor_1.4.3-1.dsc More information about hello can be obtained from https://salsa.debian.org/pkg-deepin-team/deepin-system-monitor Changes since the last upload: * Initial release. * Add a patch to prevent /usr/share/dman/* from being installed, more info can be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883379#33 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883379#45 -- Yanhao Mo signature.asc Description: PGP signature
