[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110616084720.GA2897@albatros>
Date: Thu, 16 Jun 2011 12:47:20 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc: linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com,
akpm@...ux-foundation.org, gregkh@...e.de, davem@...emloft.net,
arnd@...db.de, viro@...iv.linux.org.uk, rientjes@...gle.com,
wilsons@...rt.ca, daniel.lezcano@...e.fr, ebiederm@...ssion.com,
serge@...lyn.com
Subject: Re: [RFC 2/5 v4] procfs: add hidepid= and gid= mount options
Hi KOSAKI,
On Thu, Jun 16, 2011 at 11:24 +0900, KOSAKI Motohiro wrote:
> Maybe I missed patch [0/5] or I haven't got it. Anyway I haven't see it.
0/5: https://lkml.org/lkml/2011/6/15/172 As 0's description doesn't go
into "git log", I didn't put exhaustive explaination there.
Documentation: https://lkml.org/lkml/2011/6/15/176
> Can you please describe your use case? Why do we need two new hidepid mode?
It can be used everywhere where a confidence is an issue. The most
visible part is cmdline and comm hiding, which forbids learning what
binaries other users run. status, perhaps io, stat and sched may be
indirectly used for the same purpose. These and other files may be used
for gaining indirect infomation about what kinds (and/or what amount) of
computations were performed.
Changing all these files' permissions is arguable (it's not obvious what
files are sources of potential infoleaks and in what cases), it might
lead to compatibility issues.
> Moreover, if we use hidepid=[12], it may break some procps tools. What do
> you think about compatibility issue?
Good question :) In times of -ow patch there was a pstree patch to show
independent process trees:
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/psmisc/psmisc-21.5-owl-restricted-proc.diff?rev=1.2;content-type=text%2Fplain
It is simple to port it to the latest version of pstree. Current
version of pstree prints only one tree:
?─┬─bonobo-activati───{bonobo-activat}
├─clock-applet
├─cpufreq-applet
├─dbus-daemon
├─dbus-launch
[...]
I didn't spot any visibility issues with other process related tools -
ps and similar just print accessible processes' information skipping
nonaccessible ones.
> And, why don't you use just pid namespace?
Pid namespaces are somewhat good, but it is already possible to use
different security domains (uid and gid) inside of pid_namespace without
any trust between them (OK, root is an exception :)). Hidepid enhances
already implemented separation. Sometimes pid namespace's separation
may be too strong (no process-related communications between processes
of different namespaces unless they are parent and child namespaces).
Besides, namespaces are very expensive resource in sense of memory.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
