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

[Andy Lutomirski]

On Tue, Dec 15, 2015 at 7:53 AM, Andrew Vagin <avagin@xxxxxxxxxxxxx> wrote:
> On Mon, Dec 14, 2015 at 02:38:06PM -0800, Andy Lutomirski wrote:
>> On Dec 13, 2015 11:52 PM, "Andrew Vagin" <avagin@xxxxxxxxxxxxx> wrote:
>> >
>> > On Thu, Dec 03, 2015 at 03:20:30PM -0800, Andy Lutomirski wrote:
>> > > On Tue, Nov 24, 2015 at 7:18 AM, Andrew Vagin <avagin@xxxxxxxxxxxxx> wrote:
>> > > > Hello Everybody,
>> > > >
>> > > > Sorry for the long delay. I wanted to resurrect this thread.
>> > > >
>> > > > Andy suggested to create a new syscall instead of using netlink
>> > > > interface.
>> > > >> Would it make more sense to have a new syscall instead?  You could
>> > > >> even still use nlattr formatting for the syscall results.
>> > > >
>> > > > I tried to implement it to understand how it looks like. Here is my
>> > > > version:
>> > > > https://github.com/avagin/linux-task-diag/blob/task_diag_syscall/kernel/task_diag.c#L665
>> > > > I could not invent a better interfaces for it than using netlink
>> > > > messages as arguments. I know it looks weird.
>> > > >
>> > > > I could not say that I understood why a new system call is better
>> > > > than using a netlink socket, so I tried to solve the problem which
>> > > > were mentioned for the netlink interface.
>> > > >
>> > > > The magor question was how to support pid and user namespaces in task_diag.
>> > > > I think I found a good and logical solution.
>> > > >
>> > > > As for pidns, we can use scm credentials, which is connected to each
>> > > > socket message. They contain requestorâs pid and we can get a pid
>> > > > namespace from it. In this case, we get a good feature to specify a pid
>> > > > namespace without entering into it. For that, an user need to specify
>> > > > any process from this pidns in an scm message.
>> > >
>> > > That seems a little messy.  A process can't currently move into
>> > > another pidns, but how do you make sure you have any pid at all that
>> > > belongs to the reference pidns?  You can, of course, always use your
>> > > own pid, but that still seems odd to me.
>> >
>> > There is your pid by default, you need to do nothing for that.
>> > If we look at containers or sandboxes, we ussualy know PID of
>> > the init process.
>> >
>> >
>> > >
>> > > >
>> > > > As for credentials, we can get them from file->f_cred. In this case we
>> > > > are able to create a socket and decrease permissions of the current
>> > > > process, but the socket will work as before. Itâs the common behaviour for
>> > > > file descriptors.
>> > >
>> > > Slightly off-topic, but this netlink is really rather bad as an
>> > > example of how fds can be used as capabilities (in the real capability
>> > > sense, not the Linux capabilities sense).  You call socket and get a
>> > > socket.  That socket captures f_cred.  Then you drop privs, and you
>> > > assume that the socket you're holding on to retains the right to do
>> > > certain things.
>> > >
>> > > This breaks pretty badly when, through things such as this patch set,
>> > > existing code that creates netlink sockets suddenly starts capturing
>> > > brand-new rights that didn't exist as part of a netlink socket before.
>> >
>> > Sorry, I don't understand this part. Could you eloborate? Maybe give an
>> > example.
>> >
>> > I always think that it's a feature, that we can create a descriptor and
>> > drop capabilities of the process or send this descriptor to an
>> > unprivilieged process.
>>
>> Suppose there's an existing program that likes this feature.  It
>> creates a netlink socket, optionally calls connect(2), and then drop
>> privileges.  It expects to retain some subset of its privileges.
>>
>> The problem is that by increasing the power of a netlink socket
>> created with higher-than-current privilege, you've just increased the
>> privilege retained by the old app.  In this particular case, it's
>> especially odd because it retains privilege over the old pidns,
>> whereas the old program (in theory -- probably no one does this) could
>> have created a netlink socket, unshared pidns, and forked, and it
>> would have expected to retain no privilege over the old pidns.
>
> Thank you for the explanation.  If I understand you correctly, the
> problem is that we can use an arbitrary netlink socket to use task_diag.
>
> It can be a reason to not use netlink interface for task diag.

Agreed.  FWIW, it's not the end of the world -- netlink is probably
already so leaky in this respect that there's no real security loss,
although the extra namespace capture (pid instead of net) makes me a
bit nervous.

I suppose we could add an ioctl to netlink that says "enable pidns
access" and that has to be called while still privileged.  (/me
ducks).

>
> What do you think about the idea to add a a transaction file in
> procfs? We will open it, send a request and get required information.
>
> I want to have a file descriptor to transfer data between kernel and
> userspace, because a size of response can be too big to receive it for
> one call. If we use a file descriptor, we can divide a response into
> parts.

I think I'm okay with that.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/