James Bottomley [off-list ref] writes:
On Fri, 2016-07-08 at 18:52 -0500, Eric W. Biederman wrote:
quoted
James Bottomley [off-list ref] writes:
quoted
On July 8, 2016 1:38:19 PM PDT, Andrew Vagin [off-list ref]
wrote:
quoted
quoted
What do you think about the idea to mount nsfs and be able to
look up any alive namespace by inum:
I think I like it. It will give us a way to enter any extant
namespace. It will work for Eric's fs namespaces as well. Perhaps
a /process/ns/<inum> Directory?
As you understood, I meant /proc/ns/<inum> (damn mobile phone
completions).
quoted
*Shivers*
That makes it very easy to bypass any existing controls that exist
for getting at namespaces. It is true that everything of that kind
is directory based but still.
Plus I think it would serve as information leak to information
outside of the container.
An operation to get a user namespace file descriptor from some kernel
object sounds reasonably sane.
A great big list of things sounds about as scary as it can get. This
is not the time to be making it easier to escape from containers.
To be honest, I think this argument is rubbish. If we're afraid of
giving out a list of all the namespaces, it means we're afraid there's
some security bug and we're trying to obscure it by making the list
hard to get. All we've done is allayed fears about the bug but the
hackers still know the portals to get through.
If such a bug exists, it will be possible to exploit it by simply
reconstructing the information from the individual process directories,
so obscurity doesn't protect us and all it does is give us a false
sense of security. If such a bug doesn't exist, then all the security
mechanisms currently in place (like no re-entry to prior namespace)
should protect us and we can give out the list.
Let's deal with the world as we'd like it to be (no obscure namespace
bugs) and accept the consequences and the responsibility for fixing
them if we turn out to be slightly incorrect. We'll end up in a far
better place than security by obscurity would land us.
No. That is not the fear. The permission checks on /proc/self/ns/xxx
are different than if the namespace is bind mounted somewhere.
That was done deliberately and with a reasonable amount of forethought.
You are asking to throw those permission checks out. The answer is no.
Furthermore there is a much clearer reason not to go with a list of all
namespaces. A list of all namespaces breaks CRIU. As you have described
it the list will change depending upon which machine you restore a
checkpoint on. I honestly don't know what kind of havoc that will cause
but it is certainly something we won't be able to checkpoint no matter
how hard we try.
A global list of namespaces especially of the kind that you can open
and get a handle to the namespace is just not appropriate.
I know inode numbers comes darn close to names but they aren't really
names and if it comes to it we can figure out how to preserve an
applications view of it all across a checkpoint/restart. So far it
hasn't proven necessary to preserve any inode numbers across
checkpoint/restart but again it is theoretically possible if it becomes
necessary.
Throwing away checkpoint/restart support for the sake of
checkpoint/restart is a no-go.
Containers fundamentally imply you don't have global visibility,
and that is a good thing.
Eric
On Fri, Jul 08, 2016 at 10:05:18PM -0500, Eric W. Biederman wrote:
James Bottomley [off-list ref] writes:
quoted
On Fri, 2016-07-08 at 18:52 -0500, Eric W. Biederman wrote:
quoted
James Bottomley [off-list ref] writes:
quoted
On July 8, 2016 1:38:19 PM PDT, Andrew Vagin [off-list ref]
wrote:
quoted
quoted
What do you think about the idea to mount nsfs and be able to
look up any alive namespace by inum:
I think I like it. It will give us a way to enter any extant
namespace. It will work for Eric's fs namespaces as well. Perhaps
a /process/ns/<inum> Directory?
As you understood, I meant /proc/ns/<inum> (damn mobile phone
completions).
quoted
*Shivers*
That makes it very easy to bypass any existing controls that exist
for getting at namespaces. It is true that everything of that kind
is directory based but still.
Plus I think it would serve as information leak to information
outside of the container.
An operation to get a user namespace file descriptor from some kernel
object sounds reasonably sane.
A great big list of things sounds about as scary as it can get. This
is not the time to be making it easier to escape from containers.
To be honest, I think this argument is rubbish. If we're afraid of
giving out a list of all the namespaces, it means we're afraid there's
some security bug and we're trying to obscure it by making the list
hard to get. All we've done is allayed fears about the bug but the
hackers still know the portals to get through.
If such a bug exists, it will be possible to exploit it by simply
reconstructing the information from the individual process directories,
so obscurity doesn't protect us and all it does is give us a false
sense of security. If such a bug doesn't exist, then all the security
mechanisms currently in place (like no re-entry to prior namespace)
should protect us and we can give out the list.
Let's deal with the world as we'd like it to be (no obscure namespace
bugs) and accept the consequences and the responsibility for fixing
them if we turn out to be slightly incorrect. We'll end up in a far
better place than security by obscurity would land us.
No. That is not the fear. The permission checks on /proc/self/ns/xxx
are different than if the namespace is bind mounted somewhere.
That was done deliberately and with a reasonable amount of forethought.
You are asking to throw those permission checks out. The answer is no.
Furthermore there is a much clearer reason not to go with a list of all
namespaces. A list of all namespaces breaks CRIU. As you have described
it the list will change depending upon which machine you restore a
checkpoint on. I honestly don't know what kind of havoc that will cause
but it is certainly something we won't be able to checkpoint no matter
how hard we try.
It's right. I hadn't thought about this.
A global list of namespaces especially of the kind that you can open
and get a handle to the namespace is just not appropriate.
I know inode numbers comes darn close to names but they aren't really
names and if it comes to it we can figure out how to preserve an
applications view of it all across a checkpoint/restart. So far it
hasn't proven necessary to preserve any inode numbers across
checkpoint/restart but again it is theoretically possible if it becomes
necessary.
Throwing away checkpoint/restart support for the sake of
checkpoint/restart is a no-go.
Containers fundamentally imply you don't have global visibility,
and that is a good thing.
All these thoughts about security make me thinking that kcmp is what we
should use here. It's maybe something like this:
kcmp(pid1, pid2, KCMP_NS_USERNS, fd1, fd2)
- to check if userns of the fd1 namepsace is equal to the fd2 userns
kcmp(pid1, pid2, KCMP_NS_PARENT, fd1, fd2)
- to check if a parent namespace of the fd1 pidns is equal to fd pidns.
fd1 and fd2 is file descriptors to namespace files.
So if we want to build a hierarchy, we need to collect all namespaces
and then enumerate them to check dependencies with help of kcmp.
Eric
On July 9, 2016 4:26:28 PM GMT+09:00, Andrew Vagin [off-list ref] wrote:
On Fri, Jul 08, 2016 at 10:05:18PM -0500, Eric W. Biederman wrote:
quoted
James Bottomley [off-list ref] writes:
quoted
On Fri, 2016-07-08 at 18:52 -0500, Eric W. Biederman wrote:
quoted
James Bottomley [off-list ref] writes:
quoted
On July 8, 2016 1:38:19 PM PDT, Andrew Vagin
[off-list ref]
quoted
quoted
quoted
quoted
wrote:
quoted
quoted
What do you think about the idea to mount nsfs and be able to
look up any alive namespace by inum:
I think I like it. It will give us a way to enter any extant
namespace. It will work for Eric's fs namespaces as well.
Perhaps
quoted
quoted
quoted
quoted
a /process/ns/<inum> Directory?
As you understood, I meant /proc/ns/<inum> (damn mobile phone
completions).
quoted
*Shivers*
That makes it very easy to bypass any existing controls that exist
quoted
quoted
quoted
for getting at namespaces. It is true that everything of that
kind
quoted
quoted
quoted
is directory based but still.
Plus I think it would serve as information leak to information
outside of the container.
An operation to get a user namespace file descriptor from some
kernel
quoted
quoted
quoted
object sounds reasonably sane.
A great big list of things sounds about as scary as it can get.
This
quoted
quoted
quoted
is not the time to be making it easier to escape from containers.
To be honest, I think this argument is rubbish. If we're afraid of
giving out a list of all the namespaces, it means we're afraid
there's
quoted
quoted
some security bug and we're trying to obscure it by making the list
hard to get. All we've done is allayed fears about the bug but the
hackers still know the portals to get through.
If such a bug exists, it will be possible to exploit it by simply
reconstructing the information from the individual process
directories,
quoted
quoted
so obscurity doesn't protect us and all it does is give us a false
sense of security. If such a bug doesn't exist, then all the
security
quoted
quoted
mechanisms currently in place (like no re-entry to prior namespace)
should protect us and we can give out the list.
Let's deal with the world as we'd like it to be (no obscure
namespace
quoted
quoted
bugs) and accept the consequences and the responsibility for fixing
them if we turn out to be slightly incorrect. We'll end up in a
far
quoted
quoted
better place than security by obscurity would land us.
No. That is not the fear. The permission checks on
/proc/self/ns/xxx
quoted
are different than if the namespace is bind mounted somewhere.
That was done deliberately and with a reasonable amount of
forethought.
quoted
You are asking to throw those permission checks out. The answer is
no.
quoted
Furthermore there is a much clearer reason not to go with a list of
all
quoted
namespaces. A list of all namespaces breaks CRIU. As you have
described
quoted
it the list will change depending upon which machine you restore a
checkpoint on. I honestly don't know what kind of havoc that will
cause
quoted
but it is certainly something we won't be able to checkpoint no
matter
quoted
how hard we try.
It's right. I hadn't thought about this.
Me neither. Sorry for the prior outburst.
I think this means we're back to exposing owning userns in the /proc /<pid >/ns directory.
quoted
A global list of namespaces especially of the kind that you can open
and get a handle to the namespace is just not appropriate.
I know inode numbers comes darn close to names but they aren't really
names and if it comes to it we can figure out how to preserve an
applications view of it all across a checkpoint/restart. So far it
hasn't proven necessary to preserve any inode numbers across
checkpoint/restart but again it is theoretically possible if it
becomes
quoted
necessary.
Throwing away checkpoint/restart support for the sake of
checkpoint/restart is a no-go.
Containers fundamentally imply you don't have global visibility,
and that is a good thing.
All these thoughts about security make me thinking that kcmp is what we
should use here. It's maybe something like this:
kcmp(pid1, pid2, KCMP_NS_USERNS, fd1, fd2)
- to check if userns of the fd1 namepsace is equal to the fd2 userns
kcmp(pid1, pid2, KCMP_NS_PARENT, fd1, fd2)
- to check if a parent namespace of the fd1 pidns is equal to fd pidns.
fd1 and fd2 is file descriptors to namespace files.
So if we want to build a hierarchy, we need to collect all namespaces
and then enumerate them to check dependencies with help of kcmp.
Sure, but we need a method for opening the filehandles first .. .
James
quoted
Eric
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On July 9, 2016 4:26:28 PM GMT+09:00, Andrew Vagin [off-list ref] wrote:
On Fri, Jul 08, 2016 at 10:05:18PM -0500, Eric W. Biederman wrote:
quoted
James Bottomley [off-list ref] writes:
quoted
On Fri, 2016-07-08 at 18:52 -0500, Eric W. Biederman wrote:
quoted
James Bottomley [off-list ref] writes:
quoted
On July 8, 2016 1:38:19 PM PDT, Andrew Vagin
[off-list ref]
quoted
quoted
quoted
quoted
wrote:
quoted
quoted
What do you think about the idea to mount nsfs and be able to
look up any alive namespace by inum:
I think I like it. It will give us a way to enter any extant
namespace. It will work for Eric's fs namespaces as well.
Perhaps
quoted
quoted
quoted
quoted
a /process/ns/<inum> Directory?
As you understood, I meant /proc/ns/<inum> (damn mobile phone
completions).
quoted
*Shivers*
That makes it very easy to bypass any existing controls that exist
quoted
quoted
quoted
for getting at namespaces. It is true that everything of that
kind
quoted
quoted
quoted
is directory based but still.
Plus I think it would serve as information leak to information
outside of the container.
An operation to get a user namespace file descriptor from some
kernel
quoted
quoted
quoted
object sounds reasonably sane.
A great big list of things sounds about as scary as it can get.
This
quoted
quoted
quoted
is not the time to be making it easier to escape from containers.
To be honest, I think this argument is rubbish. If we're afraid of
giving out a list of all the namespaces, it means we're afraid
there's
quoted
quoted
some security bug and we're trying to obscure it by making the list
hard to get. All we've done is allayed fears about the bug but the
hackers still know the portals to get through.
If such a bug exists, it will be possible to exploit it by simply
reconstructing the information from the individual process
directories,
quoted
quoted
so obscurity doesn't protect us and all it does is give us a false
sense of security. If such a bug doesn't exist, then all the
security
quoted
quoted
mechanisms currently in place (like no re-entry to prior namespace)
should protect us and we can give out the list.
Let's deal with the world as we'd like it to be (no obscure
namespace
quoted
quoted
bugs) and accept the consequences and the responsibility for fixing
them if we turn out to be slightly incorrect. We'll end up in a
far
quoted
quoted
better place than security by obscurity would land us.
No. That is not the fear. The permission checks on
/proc/self/ns/xxx
quoted
are different than if the namespace is bind mounted somewhere.
That was done deliberately and with a reasonable amount of
forethought.
quoted
You are asking to throw those permission checks out. The answer is
no.
quoted
Furthermore there is a much clearer reason not to go with a list of
all
quoted
namespaces. A list of all namespaces breaks CRIU. As you have
described
quoted
it the list will change depending upon which machine you restore a
checkpoint on. I honestly don't know what kind of havoc that will
cause
quoted
but it is certainly something we won't be able to checkpoint no
matter
quoted
how hard we try.
It's right. I hadn't thought about this.
Me neither. Sorry for the prior outburst.
I think this means we're back to exposing owning userns in the /proc /<pid >/ns directory.
quoted
A global list of namespaces especially of the kind that you can open
and get a handle to the namespace is just not appropriate.
I know inode numbers comes darn close to names but they aren't really
names and if it comes to it we can figure out how to preserve an
applications view of it all across a checkpoint/restart. So far it
hasn't proven necessary to preserve any inode numbers across
checkpoint/restart but again it is theoretically possible if it
becomes
quoted
necessary.
Throwing away checkpoint/restart support for the sake of
checkpoint/restart is a no-go.
Containers fundamentally imply you don't have global visibility,
and that is a good thing.
All these thoughts about security make me thinking that kcmp is what we
should use here. It's maybe something like this:
kcmp(pid1, pid2, KCMP_NS_USERNS, fd1, fd2)
- to check if userns of the fd1 namepsace is equal to the fd2 userns
kcmp(pid1, pid2, KCMP_NS_PARENT, fd1, fd2)
- to check if a parent namespace of the fd1 pidns is equal to fd pidns.
fd1 and fd2 is file descriptors to namespace files.
So if we want to build a hierarchy, we need to collect all namespaces
and then enumerate them to check dependencies with help of kcmp.
Sure, but we need a method for opening the filehandles first .. .
James
quoted
Eric
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.