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