Lukasz Pawelczyk [off-list ref] writes:
On czw, 2014-11-27 at 09:42 -0600, Eric W. Biederman wrote:
quoted
Lukasz Pawelczyk [off-list ref] writes:
quoted
On czw, 2014-11-27 at 16:01 +0100, Richard Weinberger wrote:
quoted
Am 27.11.2014 um 15:44 schrieb Lukasz Pawelczyk:
quoted
True, the last one is 0x80000000. I did not notice that. Thanks for
pointing out.
Isn't this CLONE_IO?
Yes, I was merely noticing out loud that it's the last bit of 32bit.
After close look though the 0x00001000 appears to be unused
quoted
quoted
Any suggestion on what can be done here? New syscal with flags2?
I'm not sure. But a new syscall would be a candidate.
We are probably going to need to go a couple rounds with this but at
first approximation I think this functionality needs to be tied to the
user namespace. This functionality already looks half tied to it.
When mounting filesystems with user namespaces priveleges matures a
little more you should be able to use unmapped labels. In the near term
we are looking at filesystems such as tmpfs, fuse and posibly extN.
I presume you are referring to the Smack namespace readme where I
mentioned mounts with specifying smack labels in the mount options, not
to the quote above?
I was referring the to the check here that has been changed to
smack_ns_privileged() using ns_capable():
http://lxr.free-electrons.com/source/security/smack/smack_lsm.c#L462
And you can't use an unmapped Smack label inside the namespace, this
would be completely against its idea.
Anyway, at this point I'm more interested in the LSM namespace. I'll be
doing an RFC for Smack namespace later.
Unless I misunderstood your mail.
I had two points.
a) Tie the label mapping to the user namespace, then we don't need any
new namespaces.
Is there a reason not to tie the label mapping to the user namespace?
Needing to modify every userspace that create containers to know
about every different lsm looks like a maintenance difficulty I would
prefer to avoid.
b) For filesystems that don't need uid mapping (say ext2 mounted with
user namespace permissions) we shouldn't need LSM mapping either.
Eric
On czw, 2014-11-27 at 10:44 -0600, Eric W. Biederman wrote:
Lukasz Pawelczyk [off-list ref] writes:
quoted
On czw, 2014-11-27 at 09:42 -0600, Eric W. Biederman wrote:
quoted
quoted
We are probably going to need to go a couple rounds with this but at
first approximation I think this functionality needs to be tied to the
user namespace. This functionality already looks half tied to it.
Actually it's not. You can create LSM/Smack namespace without user
namespace and it works properly.
quoted
quoted
When mounting filesystems with user namespaces priveleges matures a
little more you should be able to use unmapped labels. In the near term
we are looking at filesystems such as tmpfs, fuse and posibly extN.
Ok, I get the idea now. But still think it wouldn't do well with the
Smack namespace. It would basically allow you to operate on something
that the administrator did not allowed you to (by filling the labels'
map).
If the user namespace allows such a thing now I was not aware. I'll have
a look.
I had two points.
a) Tie the label mapping to the user namespace, then we don't need any
new namespaces.
Is there a reason not to tie the label mapping to the user namespace?
I remember that I entertained the idea when I started the work on that
and for some reason went against it.
Right now the major issue I see is that LSM by itself is not defined how
it's going to behave. It's up to a specific LSM module.
E.g. within the Smack namespace filling the map is a privileged
operation. So by tying them up you cripple the ability to create a fully
working user namespace as an unprivileged process.
I want to have Smack namespace be able to map its own label without
privileges (as user namespace can do with its own UID) but for now it's
not the case and I'm not sure it will ever be.
With other LSM implementation other limitations might apply.
Besides a use case (with other LSM modules) when someone might not want
to create an LSM namespace might be valid as well.
Needing to modify every userspace that create containers to know
about every different lsm looks like a maintenance difficulty I would
prefer to avoid.
The LSM namespace is only one, it's not like every LSM modules creates a
different namespace. The LSM namespace is created for the LSM module
that is active at the moment. And user space might need to be aware of
them anyway as e.g. Smack requires you to create labels' map. Other
modules might require something different.
BTW: have you read the Smack-namespace readme I pasted in the cover
letter? It describes the idea behind namespace implementation in that
particular module.
--
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics
On czw, 2014-11-27 at 18:38 +0100, Lukasz Pawelczyk wrote:
Right now the major issue I see is that LSM by itself is not defined how
it's going to behave. It's up to a specific LSM module.
E.g. within the Smack namespace filling the map is a privileged
operation. So by tying them up you cripple the ability to create a fully
working user namespace as an unprivileged process.
Entertaining the idea that LSM namespace would be tied to user namespace
(as you suggested) how do you see the limitation I described above?
--
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics