Boruch Baum <boruch_b...@gmx.com> writes: - some clarifications as I tend to forget how far remove from 'everyday experiences' this stuff happens to be -
> On 04/04/2016 11:22 AM, Rainer Weikusat wrote: [...] >> [*] "Everyday real-world example": One of the things I'm dealing with >> is a proprietary racoon fork part of a VPN product for mobiles >> (hefty simplification). I usually don't work on code as root but in >> case I need to run a debugging session, I have to run the debugger as >> root as it will need to be able to control a privileged process, >> namely, the IKE daemon. Being prevented from seeing my own processes >> via ps because they happen to be running with elevated privileges >> would at least be a nuisance. > You're trying to make a case for lowering system security using an > example of a project meant to raise system security. It seems to me, as > an outsider to your case, that you would be compromising your ipsec > efforts There are no "IPsec efforts" to compromise here -- I'm working as developer on a product which includes racoon (IKEv1 implementation) and whose purpose (one of them, at least) is to provide remote access VPNs to iOS, OS X, Windows and Android devices. The machines in question here would either be development servers run by my employer or production appliances. VPN user itself have no access to either system, only 'tech staff' has. [...] > Finally, in the case you mentioned, I'm not certain I understand what > you mean when you say you would be "prevented from seeing my own > processes via ps because they happen to be running with elevated > privileges" - you said earlier that you run the debugger as root, and as > root you would be seeing ALL processes. I'm running the debugger as root via sudo. But not any other shell session on the same computer. > If you're not running as root, you would still be seeing all the other > processes of your shared group. Also, there's a plethora of processes involved here using many different user and group IDs, depending on what kind of privileges they need and what access to generally protected information they require. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
