linux-kernel - Re: procfs: boot- and runtime configurable access mode for /proc/<pid> dirs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D8B9253.7030107@nachtgeist.net>
Date:	Thu, 24 Mar 2011 19:49:55 +0100
From:	Daniel Reichelt <debian@...htgeist.net>
To:	Alexey Dobriyan <adobriyan@...il.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: procfs: boot- and runtime configurable access mode for /proc/<pid>
 dirs

>> Why exactly? Since it's only a char and not char[] I don't see the
>> disadvantage over int or a define or whatever. Of course I could always
>> change that if that's a de-facto standard I just didn't know about.
> 
> Keep mode_t inside kernel, this will get rid of many ifdefs.

Too obvious, point made.


>> Use-case is to isolate process information from other users' or groups'
>> eyes, e.g. with 550 the output of ps aux only lists processes of the
>> groups your user is a member of.
> 
> This is doable with some ps(1) switch, I'm sure.
> 
> The content of /proc/$PID directory is not a secret.

Sure, I could just run ps ux instead of ps aux and I'm done - in case I
wanna see only MY procs. That's my very point: sometimes it needs to be
a secret and not by ps-invoking-user's choice at that but by an admin's
enforcement. There are cases where I wouldn't want anybody ELSE to know
ANYTHING about my procs, not even their existence. So even when I'm root
on a box and I could restrict user-space tools...there's always another
unrestricted one. A curious user just compiles his own toy and goes fishing.

Real-world example: amongst many other (administrative) isolation
mechanisms to keep users apart, I've been using this approach for years
to enforce privacy in several hosting environments. Just think of poorly
implemented software which doesn't mask cmdline parameters like
--password. Of course one could argue "Just switch to another software."
Needless to say, that's often not option.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/