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

[Andy Lutomirski]

On Wed, Jul 8, 2015 at 3:49 PM, Andrey Vagin <avagin@xxxxxxxxxx> wrote:
> 2015-07-08 20:39 GMT+03:00 Andy Lutomirski <luto@xxxxxxxxxxxxxx>:
>> On Wed, Jul 8, 2015 at 9:10 AM, Andrew Vagin <avagin@xxxxxxxx> wrote:
>>>
>>> As far as I understand, socket_diag doesn't have this problem, becaus
>>> each socket has a link on a namespace where it was created.
>>>
>>> What if we will pin the current pidns and credentials to a task_diag
>>> socket in a moment when it's created.
>>
>> That's certainly doable.  OTOH, if anything does:
>>
>> socket(AF_NETLINK, ...);
>> unshare(CLONE_PID);
>> fork();
>>
>> then they now have a (minor) security problem.
>
> What do you mean? Is it not the same when we open a file and change
> uid and gid? Permissions are checked only in the "open" syscall.
>
> [root@avagin-fc19-cr ~]# ls -l xxx
> -rw-r--r-- 1 root root 5 Jul  9 01:42 xxx
>
> open("xxx", O_WRONLY|O_APPEND)          = 3
> setgid(1000)                            = 0
> setuid(1000)                            = 0
> write(3, "a", 1)                        = 1
> close(1)                                = 0

Yes and no.

open(2) is supposed to return an fd that retains the access to the
file that existed when open(2) was called.  socket(2) is supposed* to
capture the access to the netns that existed at the time it was
called, but capturing access to a userns and/or pidns is new.

If you added socket(AF_NETLINK, SOCK_DGRAM, NETLINK_PIDNS), then maybe
that would work, but the userns interaction is a bit odd.  OTOH every
pidns has an associated userns, so you could just use that.  I don't
know whether that would annoy someone.

* There's some question as to whether socket(2) or connect(2) should
do this, but connect handling in netlink is quite broken and iproute2
relies on the broken handling.  The historical behavior was different,
too, but the old behavior was exploitable.  I have a cute little
program that does 'ip set dev lo down' but doesn't need to be run as
root :)

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