Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1290906 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/24] kernel: add a netlink interface to get information  about processes (v2) Andrew Vagin <avagin@virtuozzo.com> - 2015-12-14 09:00 +0100
    Re: [PATCH 0/24] kernel: add a netlink interface to get information  about processes (v2) Andy Lutomirski <luto@amacapital.net> - 2015-12-14 23:40 +0100
      Re: [PATCH 0/24] kernel: add a netlink interface to get information  about processes (v2) Andrew Vagin <avagin@virtuozzo.com> - 2015-12-15 17:00 +0100
        Re: [PATCH 0/24] kernel: add a netlink interface to get information  about processes (v2) Andy Lutomirski <luto@amacapital.net> - 2015-12-15 17:50 +0100

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

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@virtuozzo.com> 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.

I think this part may be critical for understanding your point of view.
Thanks.

> 
> From my perspective, netlink is a lot like ioctl, only without the
> meaningful fd that you're calling it on.  So why is it better than
> syscalls?  I'll grant that it comes with nice (?) buffering machinery.

The nice buffering machinery is one of the reasons. Another reason is
that netlink is a ready interface for this sort of task, so we can avoid
code duplacation.

> 
> > * Netlink is designed for such type of workloads. It allows to expand
> >   the interface and save backward compatibility. It allows to generates
> >   packets with a different set of parameters.
> > * If we use a file descriptor, we can create it and decrease
> >   capabilities of the current process. It's a good feature which will be
> >   unavailable if we decide to create a system call.
> 
> If this is actually a real goal and it matters, then I'd suggest doing
> it right.  Make a way to create an fd that represents a pidns and,
> specifically, the right to query non-secret properties of the
> processes in the pidns.

I will think. Thank you for comments.

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

[toc] | [next] | [standalone]

#1291629

On Dec 13, 2015 11:52 PM, "Andrew Vagin" <avagin@virtuozzo.com> 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@virtuozzo.com> 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.

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

[toc] | [prev] | [next] | [standalone]

#1292311

On Mon, Dec 14, 2015 at 02:38:06PM -0800, Andy Lutomirski wrote:
> On Dec 13, 2015 11:52 PM, "Andrew Vagin" <avagin@virtuozzo.com> 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@virtuozzo.com> 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.

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.

Thanks,
Andrew

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

[toc] | [prev] | [next] | [standalone]

#1292345

On Tue, Dec 15, 2015 at 7:53 AM, Andrew Vagin <avagin@virtuozzo.com> wrote:
> On Mon, Dec 14, 2015 at 02:38:06PM -0800, Andy Lutomirski wrote:
>> On Dec 13, 2015 11:52 PM, "Andrew Vagin" <avagin@virtuozzo.com> 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@virtuozzo.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web