From: Casey Schaufler <casey@schaufler-ca.com>
To: Daniel J Walsh <dwalsh@redhat.com>, David Howells <dhowells@redhat.com>
Cc: linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov,
linux-fsdevel@vger.kernel.org,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 0/7] Security: Provide unioned file support
Date: Sat, 08 Nov 2014 17:31:19 -0800 [thread overview]
Message-ID: <545EC3E7.4040002@schaufler-ca.com> (raw)
In-Reply-To: <545D1575.2010708@redhat.com>
On 11/7/2014 10:54 AM, Daniel J Walsh wrote:
> On 11/07/2014 10:21 AM, David Howells wrote:
>> Casey Schaufler <casey@schaufler-ca.com> wrote:
>>
>>>>> What does this mean?
>>>> It has been decided that for the purposes of docker, all files within the
>>>> docker root fs will have the same label. We'd have to provide policy
>>>> namespacing otherwise (I think).
>>> That's just insane. "It has been decided" by who? Obviously not people
>>> who care about security policies. Maybe it's good enough for your
>>> particular use case, but labeling of files has to be up to the security
>>> module. That's what the modules are for.
>> It has been decided by the docker people that I've dealt with. I was
>> expecting there to be different labels throughout a docker image, but
>> apparently not...
> We want the equivalent of the mount option
> context="system_u:object_r:svirt_sandbox_file_t:s0:c1,c2"
Which just means that the policy used in the container is going
to have to grant access to everything running in that container
to that context. That's fine if you want to emasculate your module
within the container. But it requires that you do so, and that is
wrong.
> Which would label all of the content in the OVERLAYFS with this label.
> If we have to have a readonly label for the lower
> level and a RW Label for the context mount then that is fine with us.
> The lower level can actually just reveal the label of the INODE.
> We can take care of labeling it with a single label.
>
> If the context="LABEL" (Or its equivalent is not passed), it should get
> some kind of label based on the parent directory I would guess
> or transition rules.
>
> With docker we want to treat all contents of a container with a single
> label and then separate containers based on MCS(Svirt) separation.
That seems like a limited and rather pointless use case to me.
>>>>> What about LSMs that have multiple labels on a file?
>>>> Setting policy is something I'll have to leave to the docker people and the
>>>> administrators of systems that use docker.
>>> What does that mean? If the underlying mechanism can't do the job,
>>> how the dickens is the administrator supposed to make it happen?
>> I'm trying to make the kernel able to support a policy on this at all - not
>> actually write the policy itself. The policy may well vary depending on the
>> installation anyway.
>>
>>>> But all I'm proposing is a way to give the LSM access to both the file in
>>>> the overlay and the file in the lower fs that is leeching through into the
>>>> overlay.
>>> But your mechanisms are simultaneously incomplete and over specified.
>> Well then, specify better ones! I'm fairly certain it is incomplete and I'm
>> *trying* to get input on how it may be improved. I should've marked the
>> patches [RFC] but it didn't occur to me until just after I'd sent them (of
>> course).
I'd love to do so, but I'm frying too many kittens right now
to put the effort required into making this right. I do have
faith that this can be worked out. Sorry that I missed the implicit
[RFC]. It helps to know that feedback is still open.
>>
>> Anyway, there are a number of things one has to take account of:
>>
>> (1) There may be multiple 'views' or instances of a file in a union - and
>> each may be labelled differently.
>>
>> (2) The lower file may have xattrs attached to it that represent the security
>> policy.
>>
>> (3) The union file may have xattrs attached to it that represent the security
>> policy.
>>
>> (4) When copying the lower file up, the xattrs representing the security
>> attributes of the lower file must not be written as they may incorrectly
>> overwrite the security attributes of the union file.
>>
>> (5) There needs to be a way to set the security attributes on the union file.
>>
>> (6) When setting the attributes on the union file, the LSM might need to take
>> account of the attributes of the lower file in their derivation.
>>
>> (7) There may be no inode in the union layer on which to hang the attributes
>> for the upper file.
>>
>> (8) struct file::f_security should be used to contain the union layer
>> labellage on open files that point to a lower layer.
>>
>> (9) Ideally, file->f_path would point to the union layer and file->f_inode to
>> the lower layer when there is no upper file. However, this is not the
>> case at the moment. The file struct *only* points to the lower file or
>> the upper file and never both.
>>
>> (10) Overlayfs has an extra complication in that there are potentially three
>> files involved in any union. The lower file that is the source, the
>> upper file that where the copy-up goes and the virtual union file in the
>> overlay fs that redirects to one or the other.
>>
>> I've taken the approach that we assume that the upper file (if it exists)
>> has the same labellage as the union file.
>>
>>> Your proposal is a cop out. It may work in a limited set of cases.
>>> It is not a general solution.
>> Actually, I think the actual code interface I've proposed is pretty close to
>> being a general solution. I've given the LSM the information I have, it can
>> implement a fabulous maze of specially crafted labels if it wants to - and
>> even have multiple labels per inode or per file. The VFS does not care.
>>
>> David
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
WARNING: multiple messages have this Message-ID (diff)
From: Casey Schaufler <casey@schaufler-ca.com>
To: Daniel J Walsh <dwalsh@redhat.com>, David Howells <dhowells@redhat.com>
Cc: linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/7] Security: Provide unioned file support
Date: Sat, 08 Nov 2014 17:31:19 -0800 [thread overview]
Message-ID: <545EC3E7.4040002@schaufler-ca.com> (raw)
In-Reply-To: <545D1575.2010708@redhat.com>
On 11/7/2014 10:54 AM, Daniel J Walsh wrote:
> On 11/07/2014 10:21 AM, David Howells wrote:
>> Casey Schaufler <casey@schaufler-ca.com> wrote:
>>
>>>>> What does this mean?
>>>> It has been decided that for the purposes of docker, all files within the
>>>> docker root fs will have the same label. We'd have to provide policy
>>>> namespacing otherwise (I think).
>>> That's just insane. "It has been decided" by who? Obviously not people
>>> who care about security policies. Maybe it's good enough for your
>>> particular use case, but labeling of files has to be up to the security
>>> module. That's what the modules are for.
>> It has been decided by the docker people that I've dealt with. I was
>> expecting there to be different labels throughout a docker image, but
>> apparently not...
> We want the equivalent of the mount option
> context="system_u:object_r:svirt_sandbox_file_t:s0:c1,c2"
Which just means that the policy used in the container is going
to have to grant access to everything running in that container
to that context. That's fine if you want to emasculate your module
within the container. But it requires that you do so, and that is
wrong.
> Which would label all of the content in the OVERLAYFS with this label.
> If we have to have a readonly label for the lower
> level and a RW Label for the context mount then that is fine with us.
> The lower level can actually just reveal the label of the INODE.
> We can take care of labeling it with a single label.
>
> If the context="LABEL" (Or its equivalent is not passed), it should get
> some kind of label based on the parent directory I would guess
> or transition rules.
>
> With docker we want to treat all contents of a container with a single
> label and then separate containers based on MCS(Svirt) separation.
That seems like a limited and rather pointless use case to me.
>>>>> What about LSMs that have multiple labels on a file?
>>>> Setting policy is something I'll have to leave to the docker people and the
>>>> administrators of systems that use docker.
>>> What does that mean? If the underlying mechanism can't do the job,
>>> how the dickens is the administrator supposed to make it happen?
>> I'm trying to make the kernel able to support a policy on this at all - not
>> actually write the policy itself. The policy may well vary depending on the
>> installation anyway.
>>
>>>> But all I'm proposing is a way to give the LSM access to both the file in
>>>> the overlay and the file in the lower fs that is leeching through into the
>>>> overlay.
>>> But your mechanisms are simultaneously incomplete and over specified.
>> Well then, specify better ones! I'm fairly certain it is incomplete and I'm
>> *trying* to get input on how it may be improved. I should've marked the
>> patches [RFC] but it didn't occur to me until just after I'd sent them (of
>> course).
I'd love to do so, but I'm frying too many kittens right now
to put the effort required into making this right. I do have
faith that this can be worked out. Sorry that I missed the implicit
[RFC]. It helps to know that feedback is still open.
>>
>> Anyway, there are a number of things one has to take account of:
>>
>> (1) There may be multiple 'views' or instances of a file in a union - and
>> each may be labelled differently.
>>
>> (2) The lower file may have xattrs attached to it that represent the security
>> policy.
>>
>> (3) The union file may have xattrs attached to it that represent the security
>> policy.
>>
>> (4) When copying the lower file up, the xattrs representing the security
>> attributes of the lower file must not be written as they may incorrectly
>> overwrite the security attributes of the union file.
>>
>> (5) There needs to be a way to set the security attributes on the union file.
>>
>> (6) When setting the attributes on the union file, the LSM might need to take
>> account of the attributes of the lower file in their derivation.
>>
>> (7) There may be no inode in the union layer on which to hang the attributes
>> for the upper file.
>>
>> (8) struct file::f_security should be used to contain the union layer
>> labellage on open files that point to a lower layer.
>>
>> (9) Ideally, file->f_path would point to the union layer and file->f_inode to
>> the lower layer when there is no upper file. However, this is not the
>> case at the moment. The file struct *only* points to the lower file or
>> the upper file and never both.
>>
>> (10) Overlayfs has an extra complication in that there are potentially three
>> files involved in any union. The lower file that is the source, the
>> upper file that where the copy-up goes and the virtual union file in the
>> overlay fs that redirects to one or the other.
>>
>> I've taken the approach that we assume that the upper file (if it exists)
>> has the same labellage as the union file.
>>
>>> Your proposal is a cop out. It may work in a limited set of cases.
>>> It is not a general solution.
>> Actually, I think the actual code interface I've proposed is pretty close to
>> being a general solution. I've given the LSM the information I have, it can
>> implement a fabulous maze of specially crafted labels if it wants to - and
>> even have multiple labels per inode or per file. The VFS does not care.
>>
>> David
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
next prev parent reply other threads:[~2014-11-09 1:30 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 15:42 [PATCH 0/7] Security: Provide unioned file support David Howells
2014-11-05 15:42 ` [PATCH 1/7] Security: Provide copy-up security hooks for unioned files David Howells
2014-11-06 17:46 ` Casey Schaufler
2014-11-07 14:49 ` David Howells
2014-11-07 14:49 ` David Howells
2014-11-07 21:22 ` Paul Moore
2014-11-07 21:22 ` Paul Moore
2014-11-07 22:10 ` David Howells
2014-11-07 22:10 ` David Howells
2014-11-10 15:28 ` Paul Moore
2014-11-10 15:28 ` Paul Moore
2014-11-05 15:42 ` [PATCH 2/7] Overlayfs: Use copy-up security hooks David Howells
2014-11-07 21:39 ` Paul Moore
2014-11-07 21:39 ` Paul Moore
2014-11-07 22:05 ` David Howells
2014-11-07 22:05 ` David Howells
2014-11-10 15:45 ` Paul Moore
2014-11-10 15:45 ` Paul Moore
2014-11-05 15:42 ` [PATCH 3/7] SELinux: Stub in copy-up handling David Howells
2014-11-07 21:44 ` Paul Moore
2014-11-07 21:44 ` Paul Moore
2014-11-07 22:08 ` David Howells
2014-11-07 22:08 ` David Howells
2014-11-10 15:47 ` Paul Moore
2014-11-10 15:47 ` Paul Moore
2014-11-05 15:42 ` [PATCH 4/7] Security: Pass the union-layer file path into security_file_open() David Howells
2014-11-05 15:43 ` [PATCH 5/7] SELinux: Handle opening of a unioned file David Howells
2014-11-05 16:35 ` Stephen Smalley
2014-11-06 12:03 ` David Howells
2014-11-06 12:03 ` David Howells
2014-11-06 13:13 ` Stephen Smalley
2014-11-06 13:13 ` Stephen Smalley
2014-11-06 13:34 ` David Howells
2014-11-06 13:34 ` David Howells
2014-11-27 14:15 ` David Howells
2014-11-27 14:15 ` David Howells
2014-11-06 12:27 ` David Howells
2014-11-06 12:27 ` David Howells
2014-11-06 12:27 ` David Howells
2014-11-27 17:25 ` David Howells
2014-11-27 17:25 ` David Howells
2015-06-12 15:30 ` David Howells
2015-06-12 15:30 ` David Howells
2015-06-15 12:57 ` Stephen Smalley
2015-06-15 12:57 ` Stephen Smalley
2015-06-16 9:41 ` David Howells
2015-06-16 9:41 ` David Howells
2015-06-16 16:49 ` David Howells
2015-06-16 16:49 ` David Howells
2015-06-16 17:20 ` Stephen Smalley
2015-06-16 17:20 ` Stephen Smalley
2015-06-16 21:34 ` David Howells
2015-06-16 21:34 ` David Howells
2015-06-17 14:44 ` Stephen Smalley
2015-06-17 14:44 ` Stephen Smalley
2015-06-18 10:15 ` David Howells
2015-06-18 10:15 ` David Howells
2015-06-18 12:48 ` Stephen Smalley
2015-06-18 12:48 ` Stephen Smalley
2015-06-18 15:26 ` David Howells
2015-06-18 15:26 ` David Howells
2015-06-18 10:32 ` David Howells
2015-06-18 10:32 ` David Howells
2015-06-18 12:16 ` Stephen Smalley
2015-06-18 12:16 ` Stephen Smalley
2014-11-05 15:43 ` [PATCH 6/7] SELinux: The copy-up operation must have read permission on the lower file David Howells
2014-11-05 16:43 ` Stephen Smalley
2014-11-05 17:54 ` Stephen Smalley
2014-11-06 13:39 ` Stephen Smalley
2014-11-27 14:17 ` David Howells
2014-11-27 14:17 ` David Howells
2014-11-27 14:21 ` David Howells
2014-11-27 14:21 ` David Howells
2014-11-27 14:21 ` David Howells
2014-11-05 15:43 ` [PATCH 7/7] SELinux: Check against union and lower labels for file ops on lower files David Howells
2014-11-06 17:35 ` [PATCH 0/7] Security: Provide unioned file support Casey Schaufler
2014-11-06 17:35 ` Casey Schaufler
2014-11-06 17:58 ` David Howells
2014-11-06 17:58 ` David Howells
2014-11-06 18:40 ` Casey Schaufler
2014-11-06 18:40 ` Casey Schaufler
2014-11-07 15:21 ` David Howells
2014-11-07 15:21 ` David Howells
2014-11-07 18:54 ` Daniel J Walsh
2014-11-07 18:54 ` Daniel J Walsh
2014-11-09 1:31 ` Casey Schaufler [this message]
2014-11-09 1:31 ` Casey Schaufler
2014-11-10 13:59 ` Daniel J Walsh
2014-11-10 13:59 ` Daniel J Walsh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=545EC3E7.4040002@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=dhowells@redhat.com \
--cc=dwalsh@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.