Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1685113 > unrolled thread
| Started by | Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> |
|---|---|
| First post | 2017-07-11 17:10 +0200 |
| Last post | 2017-07-17 23:00 +0200 |
| Articles | 20 on this page of 62 — 9 participants |
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.
[PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> - 2017-07-11 17:10 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-11 19:20 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-12 02:20 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-12 02:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-12 05:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-12 13:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-12 19:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces James Morris <jmorris@namei.org> - 2017-07-12 10:10 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-12 15:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-12 19:10 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces James Morris <jmorris@namei.org> - 2017-07-13 00:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-13 02:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-13 03:10 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-13 01:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-13 02:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Theodore Ts'o <tytso@mit.edu> - 2017-07-13 03:20 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-13 04:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-13 14:20 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Theodore Ts'o <tytso@mit.edu> - 2017-07-13 18:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-13 19:10 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-13 19:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Theodore Ts'o <tytso@mit.edu> - 2017-07-13 21:20 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-13 21:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-13 23:20 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces James Morris <jmorris@namei.org> - 2017-07-18 09:10 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-13 19:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-13 19:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-13 20:00 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-13 21:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-13 23:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-14 02:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-14 13:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-14 14:20 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-14 14:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-14 15:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-14 17:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-14 19:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-14 20:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-07-14 20:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-07-14 21:00 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-07-14 22:10 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-07-14 22:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Theodore Ts'o <tytso@mit.edu> - 2017-07-14 23:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-15 01:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-07-15 01:40 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-15 02:10 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Theodore Ts'o <tytso@mit.edu> - 2017-07-14 21:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-07-14 21:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-07-14 21:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-15 02:20 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-07-16 13:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-14 21:00 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-14 21:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-13 23:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-13 23:20 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces "Serge E. Hallyn" <serge@hallyn.com> - 2017-07-13 02:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Vivek Goyal <vgoyal@redhat.com> - 2017-07-12 20:00 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-12 21:20 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2017-07-15 01:50 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-15 23:30 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Vivek Goyal <vgoyal@redhat.com> - 2017-07-17 21:00 +0200
Re: [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-07-17 23:00 +0200
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2017-07-13 19:50 +0200 |
| Message-ID | <u2Qpr-cO-1@gated-at.bofh.it> |
| In reply to | #1686784 |
Stefan Berger <stefanb@linux.vnet.ibm.com> writes: > On 07/13/2017 12:40 PM, Theodore Ts'o wrote: >> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote: >>> The concise summary: >>> >>> Today we have the xattr security.capable that holds a set of >>> capabilities that an application gains when executed. AKA setuid root exec >>> without actually being setuid root. >>> >>> User namespaces have the concept of capabilities that are not global but >>> are limited to their user namespace. We do not currently have >>> filesystem support for this concept. >> So correct me if I am wrong; in general, there will only be one >> variant of the form: >> >> security.foo@uid=15000 >> >> It's not like there will be: >> >> security.foo@uid=1000 >> security.foo@uid=2000 > > A file shared by 2 containers, one mapping root to uid=1000, the other > mapping root to uid=2000, will show these two xattrs on the host > (init_user_ns) once these containers set xattrs on that file. There is an interesting solution for shared directory trees containing executables. Overlayfs is needed if you need those directory trees to be writable and for the files to show up as owned by uid 0. An overlayfs will have to do something with the security.capable attribute. So ignoring that case. If you don't care about the ownership of the files, and read only is acceptable, and you still don't want to give these executables capabilities in the initial user namespace. What you can do is make everything owned by some non-zero uid including the security capability. Call this non-zero uid image-root. When the container starts it creates two nested user namespaces first with image-root mapped to 0. Then with the containers choice of uid mapped to 0 image-root unmapped. This will ensure the capability attributes work for all containers that share that root image. And it ensures the file are read-only from the container. So I don't think there is ever a case where we would share a filesystem image where we would need to set multiple security attributes on a file. >> Otherwise, I suspect that the architecture is going to turn around and >> bite us in the *ss eventually, because someone will want to do >> something crazy and the solution will not be scalable. > > Can you define what 'scalable' means for you in this context? > From what I can see sharing a filesystem between multiple containers > doesn't 'scale well' for virtualizing the xattrs primarily because of > size limitations of xattrs per file. Worse than that I believe you will find that filesystems are built on the assumption that there will be a small number of xattrs per file. So even if the vfs limitations were lifted the filesystem performance would suffer. Even if the filesystem performed well I believe there are other issues with stat, and simply not having so much meta-data that adminstrators and tools get confused. So I believe there are some very good fundamental reasons why we want to limit the amount of meta-data per file. Eric
[toc] | [prev] | [next] | [standalone]
| From | Theodore Ts'o <tytso@mit.edu> |
|---|---|
| Date | 2017-07-13 21:20 +0200 |
| Message-ID | <u2ROy-1dB-33@gated-at.bofh.it> |
| In reply to | #1686803 |
On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > Can you define what 'scalable' means for you in this context?
> > From what I can see sharing a filesystem between multiple containers
> > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > size limitations of xattrs per file.
>
> Worse than that I believe you will find that filesystems are built on
> the assumption that there will be a small number of xattrs per file.
> So even if the vfs limitations were lifted the filesystem performance
> would suffer.
That's why I've been pushing here. If people try to do
security.capable@uid=1000
security.capable@uid=2000
security.capable@uid=3000
security.capable@uid=4000
security.capable@uid=5000
security.capable@uid=6000
security.capable@uid=7000
security.capable@uid=8000
security.capable@uid=9000
.
.
.
... where the values of all of these will be the same, this is going
to be *awful* even if the file system can support it.
So maybe we are better off if we define an xattr
security.capable@guest-container
... so the property is that it is ignored by the host ("real")
container, and in all of the subcontainers, it will be used if the
local container root is trying to execute the file.
Now, this doesn't support the solution of the "turtles all the way
down" insane containers configuraiton.
E.g., where in one container we boot a RHEL distro, which then
launches another container running another RHEL distro, and repeat
this 1000 times, for a very deeply nested subsubsubsubsub...container.
I think this is insane and we shouldn't support this, but I know there
are people who think this is a perfectly sane thing to do.
The other thing this doesn't support is someone who wants to use IMA,
and where the every single IMA is using a different signed HMAC:
security.ima@uid=1000
security.ima@uid=2000
security.ima@uid=3000
security.ima@uid=4000
security.ima@uid=5000
security.ima@uid=6000
security.ima@uid=7000
security.ima@uid=8000
security.ima@uid=9000
.
.
.
Where each security IMA could either be a 32 byte HMAC, or worse, a
256 byte RSA signed signature. Now let's assume there are 10,000
containers, each of which needs a separate RSA signature. This sounds
insane.... but I've seen things that I've thought were more insane
coming out of containerland, so it would be nice if we can get
something signed in blood promisng that no, we would *never* do
something that insane, or better yet, make it impossible to do from an
architectural standpoint.
- Ted
[toc] | [prev] | [next] | [standalone]
| From | "Serge E. Hallyn" <serge@hallyn.com> |
|---|---|
| Date | 2017-07-13 21:50 +0200 |
| Message-ID | <u2Shz-1nj-19@gated-at.bofh.it> |
| In reply to | #1686854 |
Quoting Theodore Ts'o (tytso@mit.edu):
> On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > > Can you define what 'scalable' means for you in this context?
> > > From what I can see sharing a filesystem between multiple containers
> > > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > > size limitations of xattrs per file.
> >
> > Worse than that I believe you will find that filesystems are built on
> > the assumption that there will be a small number of xattrs per file.
> > So even if the vfs limitations were lifted the filesystem performance
> > would suffer.
>
> That's why I've been pushing here. If people try to do
>
> security.capable@uid=1000
> security.capable@uid=2000
> security.capable@uid=3000
> security.capable@uid=4000
> security.capable@uid=5000
> security.capable@uid=6000
> security.capable@uid=7000
> security.capable@uid=8000
> security.capable@uid=9000
> .
> .
> .
>
> ... where the values of all of these will be the same, this is going
> to be *awful* even if the file system can support it.
Typically users will be allocated a single range of ids, for instance
100000-200000. We might therefore consider putting a range in the uid=,
i.e. security.capable@uid=100000-200000. I don't think that's really
needed, but it's an option.
Consider that the executable will be owned by some kuid+kgid. If we
have all the xattrs you list above, then who would we have actually
owning the file? If we're chown'ing it anyway (to be root-owned but
not seutid-root), then this discussion is moot, because we'll have
to re-write the xattr after the chown. So for this to matter, we
would have an fs owned by either uid nobody in the container, or
by some special user (mapped to 100000 in the container perhaps)
which is always special-case-mapped into the container.
> So maybe we are better off if we define an xattr
>
> security.capable@guest-container
> ... so the property is that it is ignored by the host ("real")
> container, and in all of the subcontainers, it will be used if the
> local container root is trying to execute the file.
In the previous discussion we considered having 'security.capable@uid='
with no following integer, meaning that it would take effect in all
user namespaces which do not have kuid 0 as root.
This could be useful for cases like docker hosts, but note that writing
this has to require either global CAP_SETFCAP, or CAP_SETFCAP in a
user namespace that has every kuid except 0 mapped. If joe, uid 1000,
has subuids 100000-20000 delegated to him, then he must not be allowed
to write something that can affect someone with kuids 300000-400000.
-serge
[toc] | [prev] | [next] | [standalone]
| From | "Serge E. Hallyn" <serge@hallyn.com> |
|---|---|
| Date | 2017-07-13 23:20 +0200 |
| Message-ID | <u2TGG-2pl-27@gated-at.bofh.it> |
| In reply to | #1686803 |
Quoting Eric W. Biederman (ebiederm@xmission.com): > Stefan Berger <stefanb@linux.vnet.ibm.com> writes: > If you don't care about the ownership of the files, and read only is > acceptable, and you still don't want to give these executables > capabilities in the initial user namespace. What you can do is > make everything owned by some non-zero uid including the security > capability. Call this non-zero uid image-root. > > When the container starts it creates two nested user namespaces first > with image-root mapped to 0. Then with the containers choice of uid > mapped to 0 image-root unmapped. This will ensure the capability > attributes work for all containers that share that root image. And it > ensures the file are read-only from the container. > > So I don't think there is ever a case where we would share a filesystem > image where we would need to set multiple security attributes on a file. Neat idea. In fact, you can take it a step further and still have the files be owned by valid uids in the containers. The parent ns just needs to have its *root* map to a common kuid not mapped into the child namespaces, but the files can be owned by another kuid which *is* mapped into the child containers.
[toc] | [prev] | [next] | [standalone]
| From | James Morris <jmorris@namei.org> |
|---|---|
| Date | 2017-07-18 09:10 +0200 |
| Subject | Re: [PATCH v2] xattr: Enable security.capability in user namespaces |
| Message-ID | <u4uNP-7KM-13@gated-at.bofh.it> |
| In reply to | #1686784 |
On Thu, 13 Jul 2017, Stefan Berger wrote: > A file shared by 2 containers, one mapping root to uid=1000, the other mapping > root to uid=2000, will show these two xattrs on the host (init_user_ns) once > these containers set xattrs on that file. I may be missing something here, but what happens when say the uid=2000 container and associated user is deleted from the system, then another is created with the same uid? Won't this mean that you have unexpected capabilities turning up in the new container? -- James Morris <jmorris@namei.org>
[toc] | [prev] | [next] | [standalone]
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2017-07-13 19:30 +0200 |
| Message-ID | <u2Q66-8w6-5@gated-at.bofh.it> |
| In reply to | #1686779 |
Theodore Ts'o <tytso@mit.edu> writes: > On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote: >> The concise summary: >> >> Today we have the xattr security.capable that holds a set of >> capabilities that an application gains when executed. AKA setuid root exec >> without actually being setuid root. >> >> User namespaces have the concept of capabilities that are not global but >> are limited to their user namespace. We do not currently have >> filesystem support for this concept. > > So correct me if I am wrong; in general, there will only be one > variant of the form: > > security.foo@uid=15000 > > It's not like there will be: > > security.foo@uid=1000 > security.foo@uid=2000 > > Except.... if you have an Distribution root directory which is shared > by many containers, you would need to put the xattrs in the overlay > inodes. Worse, each time you launch a new container, with a new > subuid allocation, you will have to iterate over all files with > capabilities and do a copy-up operations on the xattrs in overlayfs. > So that's actually a bit of a disaster. > > So for distribution overlays, you will need to do things a different > way, which is to map the distro subdirectory so you know that the > capability with the global uid 0 should be used for the container > "root" uid, right? > > So this hack of using security.foo@uid=1000 is *only* useful when the > subcontainer root wants to create the privileged executable. You > still have to do things the other way. > > So can we make perhaps the assertion that *either*: > > security.foo > > exists, *or* > > security.foo@uid=BAR > > exists, but never both? And there BAR is exclusive to only one > instances? > > Otherwise, I suspect that the architecture is going to turn around and > bite us in the *ss eventually, because someone will want to do > something crazy and the solution will not be scalable. Yep. That is what it looks like from here. Which is why I asked the question about scalability of the xattr implementations. It looks like trying to accomodate the general case just gets us in trouble, and sets unrealistic expectations. Which strongly suggests that Serge's previous version that just reved the format of security.capable so that a uid field could be added is likely to be the better approach. I want to see what Serge and Stefan have to say but the case looks pretty clear cut at the moment. Eric
[toc] | [prev] | [next] | [standalone]
| From | Stefan Berger <stefanb@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-07-13 19:40 +0200 |
| Message-ID | <u2QfM-85-23@gated-at.bofh.it> |
| In reply to | #1686792 |
On 07/13/2017 01:14 PM, Eric W. Biederman wrote:
> Theodore Ts'o <tytso@mit.edu> writes:
>
>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote:
>>> The concise summary:
>>>
>>> Today we have the xattr security.capable that holds a set of
>>> capabilities that an application gains when executed. AKA setuid root exec
>>> without actually being setuid root.
>>>
>>> User namespaces have the concept of capabilities that are not global but
>>> are limited to their user namespace. We do not currently have
>>> filesystem support for this concept.
>> So correct me if I am wrong; in general, there will only be one
>> variant of the form:
>>
>> security.foo@uid=15000
>>
>> It's not like there will be:
>>
>> security.foo@uid=1000
>> security.foo@uid=2000
>>
>> Except.... if you have an Distribution root directory which is shared
>> by many containers, you would need to put the xattrs in the overlay
>> inodes. Worse, each time you launch a new container, with a new
>> subuid allocation, you will have to iterate over all files with
>> capabilities and do a copy-up operations on the xattrs in overlayfs.
>> So that's actually a bit of a disaster.
>>
>> So for distribution overlays, you will need to do things a different
>> way, which is to map the distro subdirectory so you know that the
>> capability with the global uid 0 should be used for the container
>> "root" uid, right?
>>
>> So this hack of using security.foo@uid=1000 is *only* useful when the
>> subcontainer root wants to create the privileged executable. You
>> still have to do things the other way.
>>
>> So can we make perhaps the assertion that *either*:
>>
>> security.foo
>>
>> exists, *or*
>>
>> security.foo@uid=BAR
>>
>> exists, but never both? And there BAR is exclusive to only one
>> instances?
>>
>> Otherwise, I suspect that the architecture is going to turn around and
>> bite us in the *ss eventually, because someone will want to do
>> something crazy and the solution will not be scalable.
> Yep. That is what it looks like from here.
>
> Which is why I asked the question about scalability of the xattr
> implementations. It looks like trying to accomodate the general
> case just gets us in trouble, and sets unrealistic expectations.
>
> Which strongly suggests that Serge's previous version that
> just reved the format of security.capable so that a uid field could
> be added is likely to be the better approach.
>
> I want to see what Serge and Stefan have to say but the case looks
> pretty clear cut at the moment.
The approach of virtualizing the xattrs on the name-side, which is what
this patch does, provides a more general approach than to virtualizing
it on the value side, which is what Serge does in his other patch for
security.capability alone. With the virtualizing on-the-value side
virtualizing the xattr becomes an exercise that needs to be repeated for
every xattr name that one would want to virtualize. With this patch you
would just add another xattr name to a list, a one-line patch in the
end. Xattr with prefixes like trusted.* need a bit more work but this
can be woven in as well
(https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f).
For virtualizing the xattrs on the 'value' side I was looking for
whether there's something like a 'wrapper' structure around the actual
value of the xattr so that that wrapper could be extended to support
different values at different uids and applied to any xattr.
Unfortunately there's no such 'wrapper'.
Stefan
>
> Eric
>
[toc] | [prev] | [next] | [standalone]
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2017-07-13 20:00 +0200 |
| Message-ID | <u2Qz7-fX-19@gated-at.bofh.it> |
| In reply to | #1686800 |
Stefan Berger <stefanb@linux.vnet.ibm.com> writes: > On 07/13/2017 01:14 PM, Eric W. Biederman wrote: >> Theodore Ts'o <tytso@mit.edu> writes: >> >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote: >>>> The concise summary: >>>> >>>> Today we have the xattr security.capable that holds a set of >>>> capabilities that an application gains when executed. AKA setuid root exec >>>> without actually being setuid root. >>>> >>>> User namespaces have the concept of capabilities that are not global but >>>> are limited to their user namespace. We do not currently have >>>> filesystem support for this concept. >>> So correct me if I am wrong; in general, there will only be one >>> variant of the form: >>> >>> security.foo@uid=15000 >>> >>> It's not like there will be: >>> >>> security.foo@uid=1000 >>> security.foo@uid=2000 >>> >>> Except.... if you have an Distribution root directory which is shared >>> by many containers, you would need to put the xattrs in the overlay >>> inodes. Worse, each time you launch a new container, with a new >>> subuid allocation, you will have to iterate over all files with >>> capabilities and do a copy-up operations on the xattrs in overlayfs. >>> So that's actually a bit of a disaster. >>> >>> So for distribution overlays, you will need to do things a different >>> way, which is to map the distro subdirectory so you know that the >>> capability with the global uid 0 should be used for the container >>> "root" uid, right? >>> >>> So this hack of using security.foo@uid=1000 is *only* useful when the >>> subcontainer root wants to create the privileged executable. You >>> still have to do things the other way. >>> >>> So can we make perhaps the assertion that *either*: >>> >>> security.foo >>> >>> exists, *or* >>> >>> security.foo@uid=BAR >>> >>> exists, but never both? And there BAR is exclusive to only one >>> instances? >>> >>> Otherwise, I suspect that the architecture is going to turn around and >>> bite us in the *ss eventually, because someone will want to do >>> something crazy and the solution will not be scalable. >> Yep. That is what it looks like from here. >> >> Which is why I asked the question about scalability of the xattr >> implementations. It looks like trying to accomodate the general >> case just gets us in trouble, and sets unrealistic expectations. >> >> Which strongly suggests that Serge's previous version that >> just reved the format of security.capable so that a uid field could >> be added is likely to be the better approach. >> >> I want to see what Serge and Stefan have to say but the case looks >> pretty clear cut at the moment. > > The approach of virtualizing the xattrs on the name-side, which is > what this patch does, provides a more general approach than to > virtualizing it on the value side, which is what Serge does in his > other patch for security.capability alone. With the virtualizing > on-the-value side virtualizing the xattr becomes an exercise that > needs to be repeated for every xattr name that one would want to > virtualize. With this patch you would just add another xattr name to a > list, a one-line patch in the end. Xattr with prefixes like trusted.* > need a bit more work but this can be woven in as well > (https://github.com/stefanberger/linux/commit/397b1a3b24045c67405fc83465e544fc865d402f). Reusable code has merit, as it reduces the maintenance burden. My big question right now is can you implement Ted's suggested restriction. Only one security.foo or secuirty.foo@... attribute ? The maintenance gains are definitely worth taking if they do not penalize the common case. > For virtualizing the xattrs on the 'value' side I was looking for > whether there's something like a 'wrapper' structure around the actual > value of the xattr so that that wrapper could be extended to support > different values at different uids and applied to any > xattr. Unfortunately there's no such 'wrapper'. Different values at different uids currently appear to be undesirable. At least for security.capable it does not appear to be useful. A wrapper structure is also a reasonable suggestion. Put it's magic number/version code where the existing version code is away we go. Do you know of cases where we will truly want to have different attributes for different containers? The case that I can think of for IMA is that the signatures want to be conntected to a key that goes with the filesystem image (so not a system key) but that would not be something that would need to be changed between containers. Eric
[toc] | [prev] | [next] | [standalone]
| From | "Serge E. Hallyn" <serge@hallyn.com> |
|---|---|
| Date | 2017-07-13 21:50 +0200 |
| Message-ID | <u2Shz-1nj-11@gated-at.bofh.it> |
| In reply to | #1686821 |
Quoting Eric W. Biederman (ebiederm@xmission.com): > Stefan Berger <stefanb@linux.vnet.ibm.com> writes: > > > On 07/13/2017 01:14 PM, Eric W. Biederman wrote: > >> Theodore Ts'o <tytso@mit.edu> writes: > >> > >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote: > >>>> The concise summary: > >>>> > >>>> Today we have the xattr security.capable that holds a set of > >>>> capabilities that an application gains when executed. AKA setuid root exec > >>>> without actually being setuid root. > >>>> > >>>> User namespaces have the concept of capabilities that are not global but > >>>> are limited to their user namespace. We do not currently have > >>>> filesystem support for this concept. > >>> So correct me if I am wrong; in general, there will only be one > >>> variant of the form: > >>> > >>> security.foo@uid=15000 > >>> > >>> It's not like there will be: > >>> > >>> security.foo@uid=1000 > >>> security.foo@uid=2000 > >>> > >>> Except.... if you have an Distribution root directory which is shared > >>> by many containers, you would need to put the xattrs in the overlay > >>> inodes. Worse, each time you launch a new container, with a new > >>> subuid allocation, you will have to iterate over all files with > >>> capabilities and do a copy-up operations on the xattrs in overlayfs. > >>> So that's actually a bit of a disaster. > >>> > >>> So for distribution overlays, you will need to do things a different > >>> way, which is to map the distro subdirectory so you know that the > >>> capability with the global uid 0 should be used for the container > >>> "root" uid, right? > >>> > >>> So this hack of using security.foo@uid=1000 is *only* useful when the > >>> subcontainer root wants to create the privileged executable. You > >>> still have to do things the other way. > >>> > >>> So can we make perhaps the assertion that *either*: > >>> > >>> security.foo > >>> > >>> exists, *or* > >>> > >>> security.foo@uid=BAR > >>> > >>> exists, but never both? And there BAR is exclusive to only one > >>> instances? > >>> > >>> Otherwise, I suspect that the architecture is going to turn around and > >>> bite us in the *ss eventually, because someone will want to do > >>> something crazy and the solution will not be scalable. > >> Yep. That is what it looks like from here. > >> > >> Which is why I asked the question about scalability of the xattr > >> implementations. It looks like trying to accomodate the general > >> case just gets us in trouble, and sets unrealistic expectations. > >> > >> Which strongly suggests that Serge's previous version that > >> just reved the format of security.capable so that a uid field could > >> be added is likely to be the better approach. > >> > >> I want to see what Serge and Stefan have to say but the case looks > >> pretty clear cut at the moment. I'm fine with that. Now, we'll be doing the enforcement at xattr write time, meaning someone *can* come up with an fs image with >1 such xattrs. Which is *fine*, I believe, it won't break anything security-wise, and our goal is only to stop users from thinking it is legitimate two write multiple such xattrs, so that they don't later bug the fs folks like Ted saying "hey why can't I write 1000 of these, I think that's a bug." So at xattr write time, 1. if there is already an xattr, and it is either the global non-namespaced xattr, or it has kuid=X where X is the kuid mapped to root in a parent of the container, then we refuse the write 2. if there is already an xattr, and it is for a kuid=X where X is mapped into the container, then we overwrite the existing xattr. At read/use time, we use the rules we have now. Does that seem reasonable? -serge
[toc] | [prev] | [next] | [standalone]
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2017-07-13 23:30 +0200 |
| Message-ID | <u2TQl-2st-7@gated-at.bofh.it> |
| In reply to | #1686868 |
"Serge E. Hallyn" <serge@hallyn.com> writes: > Quoting Eric W. Biederman (ebiederm@xmission.com): >> Stefan Berger <stefanb@linux.vnet.ibm.com> writes: >> >> > On 07/13/2017 01:14 PM, Eric W. Biederman wrote: >> >> Theodore Ts'o <tytso@mit.edu> writes: >> >> >> >>> On Thu, Jul 13, 2017 at 07:11:36AM -0500, Eric W. Biederman wrote: >> >>>> The concise summary: >> >>>> >> >>>> Today we have the xattr security.capable that holds a set of >> >>>> capabilities that an application gains when executed. AKA setuid root exec >> >>>> without actually being setuid root. >> >>>> >> >>>> User namespaces have the concept of capabilities that are not global but >> >>>> are limited to their user namespace. We do not currently have >> >>>> filesystem support for this concept. >> >>> So correct me if I am wrong; in general, there will only be one >> >>> variant of the form: >> >>> >> >>> security.foo@uid=15000 >> >>> >> >>> It's not like there will be: >> >>> >> >>> security.foo@uid=1000 >> >>> security.foo@uid=2000 >> >>> >> >>> Except.... if you have an Distribution root directory which is shared >> >>> by many containers, you would need to put the xattrs in the overlay >> >>> inodes. Worse, each time you launch a new container, with a new >> >>> subuid allocation, you will have to iterate over all files with >> >>> capabilities and do a copy-up operations on the xattrs in overlayfs. >> >>> So that's actually a bit of a disaster. >> >>> >> >>> So for distribution overlays, you will need to do things a different >> >>> way, which is to map the distro subdirectory so you know that the >> >>> capability with the global uid 0 should be used for the container >> >>> "root" uid, right? >> >>> >> >>> So this hack of using security.foo@uid=1000 is *only* useful when the >> >>> subcontainer root wants to create the privileged executable. You >> >>> still have to do things the other way. >> >>> >> >>> So can we make perhaps the assertion that *either*: >> >>> >> >>> security.foo >> >>> >> >>> exists, *or* >> >>> >> >>> security.foo@uid=BAR >> >>> >> >>> exists, but never both? And there BAR is exclusive to only one >> >>> instances? >> >>> >> >>> Otherwise, I suspect that the architecture is going to turn around and >> >>> bite us in the *ss eventually, because someone will want to do >> >>> something crazy and the solution will not be scalable. >> >> Yep. That is what it looks like from here. >> >> >> >> Which is why I asked the question about scalability of the xattr >> >> implementations. It looks like trying to accomodate the general >> >> case just gets us in trouble, and sets unrealistic expectations. >> >> >> >> Which strongly suggests that Serge's previous version that >> >> just reved the format of security.capable so that a uid field could >> >> be added is likely to be the better approach. >> >> >> >> I want to see what Serge and Stefan have to say but the case looks >> >> pretty clear cut at the moment. > > I'm fine with that. Now, we'll be doing the enforcement at xattr > write time, meaning someone *can* come up with an fs image with >1 > such xattrs. Which is *fine*, I believe, it won't break anything > security-wise, and our goal is only to stop users from thinking it > is legitimate two write multiple such xattrs, so that they don't later > bug the fs folks like Ted saying "hey why can't I write 1000 of these, > I think that's a bug." > > So at xattr write time, > > 1. if there is already an xattr, and it is either the global > non-namespaced xattr, or it has kuid=X where X is the kuid > mapped to root in a parent of the container, then we refuse > the write > 2. if there is already an xattr, and it is for a kuid=X where > X is mapped into the container, then we overwrite the existing > xattr. > > At read/use time, we use the rules we have now. > > Does that seem reasonable? That sounds like it would keep us to one xattr of any given type so yes. It occurs to me while I am writing this that this is also important for ima/evm. There is an xattr that has a hash of all of the other security relevant xattrs. Without a limit on the number of xattrs calculating that security xattr could become time prohibitive. Eric
[toc] | [prev] | [next] | [standalone]
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2017-07-14 02:50 +0200 |
| Message-ID | <u2WXT-4hp-5@gated-at.bofh.it> |
| In reply to | #1686821 |
Stefan Berger <stefanb@linux.vnet.ibm.com> writes: > On 07/13/2017 01:49 PM, Eric W. Biederman wrote: > > > My big question right now is can you implement Ted's suggested > > restriction. Only one security.foo or secuirty.foo@... attribute ? > We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done. > > So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)? > The latter. Eric
[toc] | [prev] | [next] | [standalone]
| From | Stefan Berger <stefanb@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-07-14 13:40 +0200 |
| Message-ID | <u376W-2Kc-43@gated-at.bofh.it> |
| In reply to | #1686997 |
On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>
>>> My big question right now is can you implement Ted's suggested
>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>
>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>
> The latter.
That case would prevent a container user from overriding the xattr on
the host. Is that what we want? For limiting the number of xattrs and
getting that functionality (override IMA signature for example) the
former seems better...
For the former I now have the topmost patch here:
https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
Stefan
>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[toc] | [prev] | [next] | [standalone]
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2017-07-14 14:20 +0200 |
| Message-ID | <u37JG-3iP-69@gated-at.bofh.it> |
| In reply to | #1687277 |
Stefan Berger <stefanb@linux.vnet.ibm.com> writes: > On 07/13/2017 08:38 PM, Eric W. Biederman wrote: >> Stefan Berger <stefanb@linux.vnet.ibm.com> writes: >> >>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote: >>> >>>> My big question right now is can you implement Ted's suggested >>>> restriction. Only one security.foo or secuirty.foo@... attribute ? >>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done. >>> >>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)? >>> >> The latter. > > That case would prevent a container user from overriding the xattr on > the host. Is that what we want? Most definitely. If a more privileged use has set secure.capable that is better. > For limiting the number of xattrs and > getting that functionality (override IMA signature for example) the > former seems better... I don't know about IMA. But my feeling is that we will only be dealing with a single signing key, so I don't see how having multiple IMA xattrs make sense. Could you explain that to me? > For the former I now have the topmost patch here: > https://github.com/stefanberger/linux/commits/xattr_for_userns.v3 Thank you. Eric
[toc] | [prev] | [next] | [standalone]
| From | Stefan Berger <stefanb@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-07-14 14:50 +0200 |
| Message-ID | <u38cH-3uL-9@gated-at.bofh.it> |
| In reply to | #1687324 |
On 07/14/2017 08:04 AM, Eric W. Biederman wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr on
>> the host. Is that what we want?
> Most definitely. If a more privileged use has set secure.capable that
> is better.
>
>> For limiting the number of xattrs and
>> getting that functionality (override IMA signature for example) the
>> former seems better...
> I don't know about IMA. But my feeling is that we will only be dealing
> with a single signing key, so I don't see how having multiple IMA xattrs
> make sense. Could you explain that to me?
Admittedly I would need to construct and example where the user inside
the container doesn't want to share the public key with the host on a
file mounted from the host for some reason.
An example related to security.capability could be a Fedora Docker
container where the container is distributed with the ping tool
installed. The ping tool is installed with cap_net_admin,cap_net_raw+ep.
On a normal Fedora container I cannot use this tool due to my
capabilities bounding set not including cap_net_admin. So, I overwrite
this and set only cap_net_raw+ep and I can use for pinging. I may loose
some functionality on the way due to the lost cap_net_admin but I can
now use the tool. I guess the point is one can override the capabilities
set of a distributed container if the container is started with less
capabilities.
Stefan
>
>> For the former I now have the topmost patch here:
>> https://github.com/stefanberger/linux/commits/xattr_for_userns.v3
> Thank you.
>
> Eric
>
[toc] | [prev] | [next] | [standalone]
| From | "Serge E. Hallyn" <serge@hallyn.com> |
|---|---|
| Date | 2017-07-14 15:40 +0200 |
| Message-ID | <u38Z4-44P-37@gated-at.bofh.it> |
| In reply to | #1687277 |
Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): > On 07/13/2017 08:38 PM, Eric W. Biederman wrote: > >Stefan Berger <stefanb@linux.vnet.ibm.com> writes: > > > >>On 07/13/2017 01:49 PM, Eric W. Biederman wrote: > >> > >>>My big question right now is can you implement Ted's suggested > >>>restriction. Only one security.foo or secuirty.foo@... attribute ? > >>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done. > >> > >>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)? > >> > >The latter. > > That case would prevent a container user from overriding the xattr > on the host. Is that what we want? For limiting the number of xattrs Not really. If the file is owned by a uid mapped into the container, then the container root can chown the file which will clear the file capability, after which he can set a new one. If the file is not owned by a uid mapped into the container, then container root could not set a filecap anyway. -serge
[toc] | [prev] | [next] | [standalone]
| From | Stefan Berger <stefanb@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-07-14 17:30 +0200 |
| Message-ID | <u3aHw-5hS-7@gated-at.bofh.it> |
| In reply to | #1687447 |
On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote:
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>>
>>>> On 07/13/2017 01:49 PM, Eric W. Biederman wrote:
>>>>
>>>>> My big question right now is can you implement Ted's suggested
>>>>> restriction. Only one security.foo or secuirty.foo@... attribute ?
>>>> We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.
>>>>
>>>> So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?
>>>>
>>> The latter.
>> That case would prevent a container user from overriding the xattr
>> on the host. Is that what we want? For limiting the number of xattrs
> Not really. If the file is owned by a uid mapped into the container,
> then the container root can chown the file which will clear the file
> capability, after which he can set a new one. If the file is not
> owned by a uid mapped into the container, then container root could
> not set a filecap anyway.
Let's say I installed a container where all files are signed and thus
have security.ima. Now for some reason I want to re-sign some or all
files inside that container. How would I do that ? Would I need to get
rid of security.ima first, possibly by copying each file, deleting the
original file, and renaming the copied file to the original name, or
should I just be able to write out a new signature, thus creating
security.ima@uid=1000 besides the security.ima ?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | "Serge E. Hallyn" <serge@hallyn.com> |
|---|---|
| Date | 2017-07-14 19:40 +0200 |
| Message-ID | <u3cJl-6Ez-23@gated-at.bofh.it> |
| In reply to | #1687515 |
Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: > >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): > >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote: > >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes: > >>> > >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote: > >>>> > >>>>>My big question right now is can you implement Ted's suggested > >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ? > >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done. > >>>> > >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)? > >>>> > >>>The latter. > >>That case would prevent a container user from overriding the xattr > >>on the host. Is that what we want? For limiting the number of xattrs > >Not really. If the file is owned by a uid mapped into the container, > >then the container root can chown the file which will clear the file > >capability, after which he can set a new one. If the file is not > >owned by a uid mapped into the container, then container root could > >not set a filecap anyway. > > Let's say I installed a container where all files are signed and > thus have security.ima. Now for some reason I want to re-sign some > or all files inside that container. How would I do that ? Would I > need to get rid of security.ima first, possibly by copying each > file, deleting the original file, and renaming the copied file to > the original name, or should I just be able to write out a new > signature, thus creating security.ima@uid=1000 besides the > security.ima ? > > Stefan Hi Mimi, what do you think makes most sense for IMA? -serge
[toc] | [prev] | [next] | [standalone]
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2017-07-14 20:30 +0200 |
| Message-ID | <u3dvH-7f8-9@gated-at.bofh.it> |
| In reply to | #1687583 |
"Serge E. Hallyn" <serge@hallyn.com> writes: > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: >> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote: >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes: >> >>> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote: >> >>>> >> >>>>>My big question right now is can you implement Ted's suggested >> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ? >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done. >> >>>> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)? >> >>>> >> >>>The latter. >> >>That case would prevent a container user from overriding the xattr >> >>on the host. Is that what we want? For limiting the number of xattrs >> >Not really. If the file is owned by a uid mapped into the container, >> >then the container root can chown the file which will clear the file >> >capability, after which he can set a new one. If the file is not >> >owned by a uid mapped into the container, then container root could >> >not set a filecap anyway. >> >> Let's say I installed a container where all files are signed and >> thus have security.ima. Now for some reason I want to re-sign some >> or all files inside that container. How would I do that ? Would I >> need to get rid of security.ima first, possibly by copying each >> file, deleting the original file, and renaming the copied file to >> the original name, or should I just be able to write out a new >> signature, thus creating security.ima@uid=1000 besides the >> security.ima ? >> >> Stefan > > Hi Mimi, > > what do you think makes most sense for IMA? I am going to give my two cents since I have been thinking about this. First I think this entire scheme plays hobs with the security.evm attribute as security.evm needs to know the names of the xattrs to protect. I forget which attributes has a hash and what has a message athentication code. If there is an attribute with a simple file hash I think it only make sense for the kernel to touch it, and I don't see any sense in having multiples. If there is an attribute with a message authentication code (roughly a signed hash) it makes sense to have that to be tied to the kernel key ring that controlls the keys. (Which probably means a per user namespace thing at some point). But again pretty untouchable otherwise. Which brings us to the semantic question of would it be nice to have stacked IMA/EVM on the same file. I really don't think we do. I think allowing multiple keys for different part of trusting files is easy enough that we should have no need to fight over which keys do which. Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use case I can think of for distributing a distribution image with ima/evm xattrs will need to use asymmetric keys aka public/private keypairs so that the originator of the content does not give away their private keys. Given that usefully we are talking about content that should be connected to keys in one way or another I don't believe it even makes sense at this point to attempt to use uids for dealing with ima and evm content. Further looking Serge's previous patch is 300 lines of code Setfan's patch that provides the possibility of code resuse is 500 lines of code. Increasingly it is looking to me that code reuse rather than concept reuse is a false economy. The code does not get smaller. The semantic differences make it problematic. Possibly to the problematic to the point where significant pieces may not be reused. The format breaks assumptions for other parts of the code like security.evm. The format by multiple names instead of a single attribute requires more disk access so is less efficient. In short I am seeing more code that runs slower and is harder to maintain. Please point out where I am wrong. Eric
[toc] | [prev] | [next] | [standalone]
| From | Mimi Zohar <zohar@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-07-14 20:50 +0200 |
| Message-ID | <u3dP4-7mg-1@gated-at.bofh.it> |
| In reply to | #1687583 |
On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote: > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): > > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: > > >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): > > >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote: > > >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes: > > >>> > > >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote: > > >>>> > > >>>>>My big question right now is can you implement Ted's suggested > > >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ? > > >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done. > > >>>> > > >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)? > > >>>> > > >>>The latter. > > >>That case would prevent a container user from overriding the xattr > > >>on the host. Is that what we want? For limiting the number of xattrs > > >Not really. If the file is owned by a uid mapped into the container, > > >then the container root can chown the file which will clear the file > > >capability, after which he can set a new one. If the file is not > > >owned by a uid mapped into the container, then container root could > > >not set a filecap anyway. > > > > Let's say I installed a container where all files are signed and > > thus have security.ima. Now for some reason I want to re-sign some > > or all files inside that container. How would I do that ? Would I > > need to get rid of security.ima first, possibly by copying each > > file, deleting the original file, and renaming the copied file to > > the original name, or should I just be able to write out a new > > signature, thus creating security.ima@uid=1000 besides the > > security.ima ? > > > > Stefan > > Hi Mimi, > > what do you think makes most sense for IMA? If I'm understanding the discussion correctly, this isn't an issue for layered copy on write filesystems, as each fs layer could have it's own set of xattrs. The underlying and layered xattrs should be able to co-exist. Use the layered xattr if it exists, but fall back to using the underlying xattr if it doesn't. The concern is with a shared filesystems. In that case, for IMA it would make sense to support a native and a namespace xattr. If due to xattr space limitations we have to limit the number of xattrs, then we should limit it to two - a native and a namespace version, with a "uid=" tag - first namespace gets permission to write the namespace xattr. Again, like in the layered case, if the namespace xattr doesn't exist, fall back to using the native xattr. This allows most files to use the underlying xattrs, but allows a few files to be re-signed inside the namespace, as needed. For the layered filesystem case, this would allow mutable file hashes to be written. (Unclear as to how shared filesystems would work in this case.) Mimi
[toc] | [prev] | [next] | [standalone]
| From | James Bottomley <James.Bottomley@HansenPartnership.com> |
|---|---|
| Date | 2017-07-14 21:00 +0200 |
| Message-ID | <u3dYK-7q0-7@gated-at.bofh.it> |
| In reply to | #1687603 |
On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote: > The concern is with a shared filesystems. In that case, for IMA it > would make sense to support a native and a namespace xattr. If due > to xattr space limitations we have to limit the number of xattrs, > then we should limit it to two - a native and a namespace version, > with a "uid=" tag - first namespace gets permission to write the > namespace xattr. Again, like in the layered case, if the namespace > xattr doesn't exist, fall back to using the native xattr. Just on this point: if we're really concerned about the need on shared filesystems to have multiple IMA signatures per file, might it not make sense simply to support multiple signatures within the security.ima xattr? The rules for writing signature updates within user namespaces would be somewhat complex (say only able to replace a signature for which you demonstrate you possess the key) but it would lead to an implementation which would work for traditional shared filesystems (like NFS) as well as containerised bind mounts. James
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | linux.kernel
csiph-web