linux-kernel - Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2)

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: <CALCETrVg5AyeXW_AGguFoGCPK9_2zeobEgT9JJFsakH6PyQf_A@mail.gmail.com>
Date:	Mon, 6 Jul 2015 10:10:32 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Andrey Vagin <avagin@...nvz.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Roger Luethi <rl@...lgate.ch>, Arnd Bergmann <arnd@...db.de>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	David Ahern <dsahern@...il.com>,
	Pavel Odintsov <pavel.odintsov@...il.com>
Subject: Re: [PATCH 0/24] kernel: add a netlink interface to get information
 about processes (v2)

On Mon, Jul 6, 2015 at 1:47 AM, Andrey Vagin <avagin@...nvz.org> wrote:
> Currently we use the proc file system, where all information are
> presented in text files, what is convenient for humans.  But if we need
> to get information about processes from code (e.g. in C), the procfs
> doesn't look so cool.
>
> From code we would prefer to get information in binary format and to be
> able to specify which information and for which tasks are required. Here
> is a new interface with all these features, which is called task_diag.
> In addition it's much faster than procfs.
>
> task_diag is based on netlink sockets and looks like socket-diag, which
> is used to get information about sockets.

I think I like this in principle, but I have can see a few potential
problems with using netlink for this:

1. Netlink very naturally handles net namespaces, but it doesn't
naturally handle any other kind of namespace.  In fact, the taskstats
code that you're building on has highly broken user and pid namespace
support.  (Look for some obviously useless init_user_ns and
init_pid_ns references.  But that's only the obvious problem.  That
code calls current_user_ns() and task_active_pid_ns(current) from
.doit, which is, in turn, called from sys_write, and looking at
current's security state from sys_write is a big no-no.)

You could partially fix it by looking at f_cred's namespaces, but that
would be a change of what it means to create a netlink socket, and I'm
not sure that's a good idea.

2. These look like generally useful interfaces, which means that
people might want to use them in common non-system software, which
means that some of that software might get run inside of sandboxes
(Sandstorm, xdg-app, etc.)  Sandboxes like that might block netlink
outright, since it can't be usefully filtered by seccomp.  (This isn't
really the case now, since netlink route queries are too common, but
still.)

3. Netlink is a bit tedious to use from userspace.  Especially for
things like task_diag, which are really just queries that generate
single replies.

Would it make more sense to have a new syscall instead?  You could
even still use nlattr formatting for the syscall results.

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