Boruch Baum <boruch_baum@???> writes:
> On 04/04/2016 11:22 AM, Rainer Weikusat wrote:
>> Boruch Baum <boruch_baum@???> writes:
>>> Please consider setting the default /etc/fstab to include:
>>>
>>> proc /proc proc defaults,hidepid=2
>>>
>>> This has the effect of keeping the specific activities, process
>>> ids, command lines and parameters of a user from other users.
>>
>> If you think that's useful to you, why don't you just use it.
> I do.
>
>> It's not useful to me[*] and - IMHO - generally useless on any system
>> where more than one user with privileged access works on a
>> cooperative projects.
> My understanding is that the intention of the design of the UNIX
> architecture in such cases is to have members of a 'project' be assigned
> a similar 'group' to allow mutual 'group' access.
At least for this situation (and presumably many similar ones), it's
desirable that every locally defined users has full access to all
usually public information about the system, eg, what processes are
running.
>> [*] "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.
I didn't make any statements of this generality.
> It seems to me, as an outsider to your case, that you would be
> compromising your ipsec efforts with the large and elementary security
> hole you're willing to make - to allow any one / any process to see
> every other.
In my opinion, this isn't "a large and elementary security hole". The
default behaviour is useful for me for the reasons I gave. It's further
useful in every situation where 'local users with shell access' are not
considered untrusted. Further, no system I ever had an account on which
was considered an untrusted one behaved in the way you suggest. Even on
Windows (I occasionally use for client-testing), the process list is
public.