From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with SMTP id l7DDkg6F019797 for ; Mon, 13 Aug 2007 09:46:42 -0400 Received: from web36612.mail.mud.yahoo.com (jazzhorn.ncsc.mil [144.51.5.9]) by jazzhorn.ncsc.mil (8.12.10/8.12.10) with SMTP id l7DDkVP5013305 for ; Mon, 13 Aug 2007 13:46:31 GMT Date: Mon, 13 Aug 2007 06:46:15 -0700 (PDT) From: Casey Schaufler Reply-To: casey@schaufler-ca.com Subject: Re: [PATCH 00/16] Permit filesystem local caching [try #3] To: David Howells , casey@schaufler-ca.com Cc: dhowells@redhat.com, torvalds@osdl.org, akpm@osdl.org, steved@redhat.com, trond.myklebust@fys.uio.no, linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com, nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, LSM List In-Reply-To: <24171.1187002441@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <353795.27307.qm@web36612.mail.mud.yahoo.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov --- David Howells wrote: > Casey Schaufler wrote: > > > Sigh. So it's not only SELinux specific, but RedHat specific as well. > > *Blink*. How did you come to that conclusion? > > > > (3) The cache driver wants to access the files in the cache, but it's > > > running in the security context of either the aforementioned random > > > process, or one of FS-Cache's thread pool. > > > > I think that this is the point you should attack. Control the security > > characteristics of the cache driver properly and you shouldn't need the > > complexity that you're asking to introduce. > > How? The cache driver acts on behalf of someone else. That someone else has > one security context, but the cache itself has to have a different context so > that the cache can be shared. > > Furthermore, the cache driver doesn't have a security context per se. > > > > This security context, however, doesn't necessarily give it the > > > rights to access what's in the cache, so the driver has to be > > > permitted to act as a context appropriate to accessing the cache, > > > without changing the overall security context of the random process > > > (which would impact things trying to act on that process - kill() > > > for example). > > > > Can you run the cache as an independent thread and send it messages > > rather than trying to do things in the context of the calling process? > > I know that that involves extra bookkeeppingg, but it's lots safer. > > It introduces more complexity, which I believe you were just arguing against > above... It also incurs more kernel threads - which I really really want to > avoid. > > I would rank the complexity and resource overhead of the act-as stuff in LSM > (or at least in SELinux) as much less than what you're suggesting. > > As it stands, the FS-Cache layer has a pool of threads that CacheFiles makes > use of, but this can't be bound to the security of a specific cache because > there may be more than one cache of more than one cache driver type. > > > Yes, and the SELinux semantics for what label to give a file don't > > help much, either. The problem with the "act_as" interfaces is that > > I wouldn't expect them to be any more reliable than the old access() > > system call, which never really gave you a helpful answer. > > I don't see how act_as compares to access(). > > > Ideally you want to be running in the right context to create the > > new file so that no one can use it and then label it "correctly" > > and make it available. > > That sounds like it'd be the complexity thing again... > > > > Part of the problem is that the VFS does not pass around the security > > > context as which the VFS routines act, but rather gets them from the > > > task_struct. > > > > That's by design. > > I suspect that's more by the fact that security wasn't particularly thought > about when these interfaces were first written. As with everything in the > kernel, it might be negotiable. > > > The cache driver is a unique case with an unusual function. It's pretty > > obvious that the kernel architecture, the VFS architecture, LSM, SELinux, > > NFS and pretty much everyone else has given no thought whatever to the > > implications of their designs on file system cacheing. For all concerned, > > I'll say "sorry 'bout that". > > Meaning you think I should just give up on this? No, sorry, sometimes I sound meaner than I really am. I meant that sympathetically, honest. I don't think you should give up. > How about I reduce the interface I'm proposing to two functions: > > (1) int security_act_as(struct task_struct *context) > > Temporarily make the current process act as the given task, including, > for example, for SELinux, the security ID with which this task acts on > things, and the security ID with which this task creates files. > > (2) int security_act_as_self(void); > > Restore the context as which we're asking. > > This would mean that the task's security context would have to be able to > store > acting security IDs for everything, but I don't think that's too much of a > stretch resourcewise. I haven't looked into the issues at all and I bet there are plenty, maybe in audit and places outside of the security realm, but this looks like a clean approach from the LSM interface standpoint. Do you want the entire task or just task->security? I could see it either way, but I suspect the task is your best bet. If you call security_act_as() twice, then security_act_as_self() do you pop a stack, or return to the initial state? How about security_act_as(NULL) returning you to the initial state, and dropping security_act_as_self()? Thank you for taking the effort to address the issues I raised. I appreciate your willingness to accommodate my concerns even after I'd flamed you. Casey Schaufler casey@schaufler-ca.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S947355AbXHMPiL (ORCPT ); Mon, 13 Aug 2007 11:38:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S943484AbXHMNqW (ORCPT ); Mon, 13 Aug 2007 09:46:22 -0400 Received: from web36612.mail.mud.yahoo.com ([209.191.85.29]:45369 "HELO web36612.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S973307AbXHMNqT (ORCPT ); Mon, 13 Aug 2007 09:46:19 -0400 X-YMail-OSG: .zaIZQkVM1nuHKRtssTWK7RPoAmAiz0WqoeNaDl5SGcJPjHSAevTcqkRmtCAe_fh58DIm9bB1g-- X-RocketYMMF: rancidfat Date: Mon, 13 Aug 2007 06:46:15 -0700 (PDT) From: Casey Schaufler Reply-To: casey@schaufler-ca.com Subject: Re: [PATCH 00/16] Permit filesystem local caching [try #3] To: David Howells , casey@schaufler-ca.com Cc: dhowells@redhat.com, torvalds@osdl.org, akpm@osdl.org, steved@redhat.com, trond.myklebust@fys.uio.no, linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com, nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, LSM List In-Reply-To: <24171.1187002441@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Message-ID: <353795.27307.qm@web36612.mail.mud.yahoo.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org --- David Howells wrote: > Casey Schaufler wrote: > > > Sigh. So it's not only SELinux specific, but RedHat specific as well. > > *Blink*. How did you come to that conclusion? > > > > (3) The cache driver wants to access the files in the cache, but it's > > > running in the security context of either the aforementioned random > > > process, or one of FS-Cache's thread pool. > > > > I think that this is the point you should attack. Control the security > > characteristics of the cache driver properly and you shouldn't need the > > complexity that you're asking to introduce. > > How? The cache driver acts on behalf of someone else. That someone else has > one security context, but the cache itself has to have a different context so > that the cache can be shared. > > Furthermore, the cache driver doesn't have a security context per se. > > > > This security context, however, doesn't necessarily give it the > > > rights to access what's in the cache, so the driver has to be > > > permitted to act as a context appropriate to accessing the cache, > > > without changing the overall security context of the random process > > > (which would impact things trying to act on that process - kill() > > > for example). > > > > Can you run the cache as an independent thread and send it messages > > rather than trying to do things in the context of the calling process? > > I know that that involves extra bookkeeppingg, but it's lots safer. > > It introduces more complexity, which I believe you were just arguing against > above... It also incurs more kernel threads - which I really really want to > avoid. > > I would rank the complexity and resource overhead of the act-as stuff in LSM > (or at least in SELinux) as much less than what you're suggesting. > > As it stands, the FS-Cache layer has a pool of threads that CacheFiles makes > use of, but this can't be bound to the security of a specific cache because > there may be more than one cache of more than one cache driver type. > > > Yes, and the SELinux semantics for what label to give a file don't > > help much, either. The problem with the "act_as" interfaces is that > > I wouldn't expect them to be any more reliable than the old access() > > system call, which never really gave you a helpful answer. > > I don't see how act_as compares to access(). > > > Ideally you want to be running in the right context to create the > > new file so that no one can use it and then label it "correctly" > > and make it available. > > That sounds like it'd be the complexity thing again... > > > > Part of the problem is that the VFS does not pass around the security > > > context as which the VFS routines act, but rather gets them from the > > > task_struct. > > > > That's by design. > > I suspect that's more by the fact that security wasn't particularly thought > about when these interfaces were first written. As with everything in the > kernel, it might be negotiable. > > > The cache driver is a unique case with an unusual function. It's pretty > > obvious that the kernel architecture, the VFS architecture, LSM, SELinux, > > NFS and pretty much everyone else has given no thought whatever to the > > implications of their designs on file system cacheing. For all concerned, > > I'll say "sorry 'bout that". > > Meaning you think I should just give up on this? No, sorry, sometimes I sound meaner than I really am. I meant that sympathetically, honest. I don't think you should give up. > How about I reduce the interface I'm proposing to two functions: > > (1) int security_act_as(struct task_struct *context) > > Temporarily make the current process act as the given task, including, > for example, for SELinux, the security ID with which this task acts on > things, and the security ID with which this task creates files. > > (2) int security_act_as_self(void); > > Restore the context as which we're asking. > > This would mean that the task's security context would have to be able to > store > acting security IDs for everything, but I don't think that's too much of a > stretch resourcewise. I haven't looked into the issues at all and I bet there are plenty, maybe in audit and places outside of the security realm, but this looks like a clean approach from the LSM interface standpoint. Do you want the entire task or just task->security? I could see it either way, but I suspect the task is your best bet. If you call security_act_as() twice, then security_act_as_self() do you pop a stack, or return to the initial state? How about security_act_as(NULL) returning you to the initial state, and dropping security_act_as_self()? Thank you for taking the effort to address the issues I raised. I appreciate your willingness to accommodate my concerns even after I'd flamed you. Casey Schaufler casey@schaufler-ca.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Schaufler Subject: Re: [PATCH 00/16] Permit filesystem local caching [try #3] Date: Mon, 13 Aug 2007 06:46:15 -0700 (PDT) Message-ID: <353795.27307.qm@web36612.mail.mud.yahoo.com> References: <24171.1187002441@redhat.com> Reply-To: casey@schaufler-ca.com, Linux filesystem caching discussion list Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: akpm@osdl.org, LSM List , linux-kernel@vger.kernel.org, nfsv4@linux-nfs.org, trond.myklebust@fys.uio.no, torvalds@osdl.org, linux-cachefs@redhat.com, selinux@tycho.nsa.gov, linux-fsdevel@vger.kernel.org To: David Howells , casey@schaufler-ca.com Return-path: In-Reply-To: <24171.1187002441@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-cachefs-bounces@redhat.com Errors-To: linux-cachefs-bounces@redhat.com List-Id: linux-fsdevel.vger.kernel.org --- David Howells wrote: > Casey Schaufler wrote: >=20 > > Sigh. So it's not only SELinux specific, but RedHat specific as well. >=20 > *Blink*. How did you come to that conclusion? >=20 > > > (3) The cache driver wants to access the files in the cache, but = it's > > > running in the security context of either the aforementioned = random > > > process, or one of FS-Cache's thread pool. > >=20 > > I think that this is the point you should attack. Control the securit= y > > characteristics of the cache driver properly and you shouldn't need t= he > > complexity that you're asking to introduce. >=20 > How? The cache driver acts on behalf of someone else. That someone el= se has > one security context, but the cache itself has to have a different cont= ext so > that the cache can be shared. >=20 > Furthermore, the cache driver doesn't have a security context per se. >=20 > > > This security context, however, doesn't necessarily give it t= he > > > rights to access what's in the cache, so the driver has to be > > > permitted to act as a context appropriate to accessing the ca= che, > > > without changing the overall security context of the random p= rocess > > > (which would impact things trying to act on that process - ki= ll() > > > for example). > >=20 > > Can you run the cache as an independent thread and send it messages > > rather than trying to do things in the context of the calling process= ? > > I know that that involves extra bookkeeppingg, but it's lots safer. >=20 > It introduces more complexity, which I believe you were just arguing ag= ainst > above... It also incurs more kernel threads - which I really really wa= nt to > avoid. >=20 > I would rank the complexity and resource overhead of the act-as stuff i= n LSM > (or at least in SELinux) as much less than what you're suggesting. >=20 > As it stands, the FS-Cache layer has a pool of threads that CacheFiles = makes > use of, but this can't be bound to the security of a specific cache bec= ause > there may be more than one cache of more than one cache driver type. >=20 > > Yes, and the SELinux semantics for what label to give a file don't > > help much, either. The problem with the "act_as" interfaces is that > > I wouldn't expect them to be any more reliable than the old access() > > system call, which never really gave you a helpful answer. >=20 > I don't see how act_as compares to access(). >=20 > > Ideally you want to be running in the right context to create the > > new file so that no one can use it and then label it "correctly" > > and make it available. >=20 > That sounds like it'd be the complexity thing again... >=20 > > > Part of the problem is that the VFS does not pass around the securi= ty > > > context as which the VFS routines act, but rather gets them from th= e > > > task_struct. > >=20 > > That's by design.=20 >=20 > I suspect that's more by the fact that security wasn't particularly tho= ught > about when these interfaces were first written. As with everything in = the > kernel, it might be negotiable. >=20 > > The cache driver is a unique case with an unusual function. It's pret= ty > > obvious that the kernel architecture, the VFS architecture, LSM, SELi= nux, > > NFS and pretty much everyone else has given no thought whatever to th= e > > implications of their designs on file system cacheing. For all concer= ned, > > I'll say "sorry 'bout that". >=20 > Meaning you think I should just give up on this? No, sorry, sometimes I sound meaner than I really am. I meant that sympathetically, honest. I don't think you should give up. > How about I reduce the interface I'm proposing to two functions: >=20 > (1) int security_act_as(struct task_struct *context) >=20 > Temporarily make the current process act as the given task, including, > for example, for SELinux, the security ID with which this task acts on > things, and the security ID with which this task creates files. >=20 > (2) int security_act_as_self(void); >=20 > Restore the context as which we're asking. >=20 > This would mean that the task's security context would have to be able = to > store > acting security IDs for everything, but I don't think that's too much o= f a > stretch resourcewise. I haven't looked into the issues at all and I bet there are plenty, maybe in audit and places outside of the security realm, but this looks like a clean approach from the LSM interface standpoint. Do you want the entire task or just task->security? I could see it either way, but I suspect the task is your best bet. If you call security_act_as() twice, then security_act_as_self() do you pop a stack, or return to the initial state? How about security_act_as(NULL) returning you to the initial state, and dropping security_act_as_self()? Thank you for taking the effort to address the issues I raised. I appreciate your willingness to accommodate my concerns even after I'd flamed you. Casey Schaufler casey@schaufler-ca.com