* MLS directory label inheritance rules @ 2017-04-07 18:39 Nick Kralevich 2017-04-07 18:51 ` William Roberts ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Nick Kralevich @ 2017-04-07 18:39 UTC (permalink / raw) To: SELinux When a file is created in a directory, the default label for the file is based on the label of the enclosing directory (unless something like setfscreatecon is used). For example: bullhead:/ # cd /data/misc/zoneinfo/ bullhead:/data/misc/zoneinfo # ls -ladZ . drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 1971-06-19 17:07 . bullhead:/data/misc/zoneinfo # touch asdf bullhead:/data/misc/zoneinfo # ls -ladZ . asdf drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 2017-04-07 18:32 . -rw-rw-rw- 1 root root u:object_r:zoneinfo_data_file:s0 0 2017-04-07 18:32 asdf note how the label of the "asdf" file matches the label of the enclosing directory. However, that's not true when the directory uses categories. In that case, the newly created file inherits the label, but not the categories. For example: bullhead:/data/data # cd /data/data/com.android.chrome bullhead:/data/data/com.android.chrome # ls -ladZ . drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 4096 1971-07-15 15:31 . bullhead:/data/data/com.android.chrome # touch asdf bullhead:/data/data/com.android.chrome # ls -laZd . asdf drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 4096 2017-04-07 18:35 . -rw-rw-rw- 1 root root u:object_r:app_data_file:s0 0 2017-04-07 18:35 asdf Note how the label is maintained, but the "c512,c768" portion is not maintained. While this example occurs when I'm running in a permissive domain, it also occurs in an enforcing domain. The inconsistency seems weird, and I'm sure there's a good reason why this occurs that I'm not familiar with. Can someone help me understand if this is expected, and if so, why? -- Nick Kralevich | Android Security | nnk@google.com | 650.214.4037 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MLS directory label inheritance rules 2017-04-07 18:39 MLS directory label inheritance rules Nick Kralevich @ 2017-04-07 18:51 ` William Roberts 2017-04-07 19:01 ` Dominick Grift 2017-04-07 19:41 ` Stephen Smalley 2 siblings, 0 replies; 9+ messages in thread From: William Roberts @ 2017-04-07 18:51 UTC (permalink / raw) To: Nick Kralevich; +Cc: SELinux [-- Attachment #1: Type: text/plain, Size: 2289 bytes --] On Apr 7, 2017 11:41, "Nick Kralevich" <nnk@google.com> wrote: When a file is created in a directory, the default label for the file is based on the label of the enclosing directory (unless something like setfscreatecon is used). For example: bullhead:/ # cd /data/misc/zoneinfo/ bullhead:/data/misc/zoneinfo # ls -ladZ . drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 1971-06-19 17:07 . bullhead:/data/misc/zoneinfo # touch asdf bullhead:/data/misc/zoneinfo # ls -ladZ . asdf drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 2017-04-07 18:32 . -rw-rw-rw- 1 root root u:object_r:zoneinfo_data_file:s0 0 2017-04-07 18:32 asdf note how the label of the "asdf" file matches the label of the enclosing directory. However, that's not true when the directory uses categories. In that case, the newly created file inherits the label, but not the categories. For example: bullhead:/data/data # cd /data/data/com.android.chrome bullhead:/data/data/com.android.chrome # ls -ladZ . drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 4096 1971-07-15 15:31 . bullhead:/data/data/com.android.chrome # touch asdf bullhead:/data/data/com.android.chrome # ls -laZd . asdf drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 4096 2017-04-07 18:35 . -rw-rw-rw- 1 root root u:object_r:app_data_file:s0 0 2017-04-07 18:35 asdf Note how the label is maintained, but the "c512,c768" portion is not maintained. While this example occurs when I'm running in a permissive domain, it also occurs in an enforcing domain. The inconsistency seems weird, and I'm sure there's a good reason why this occurs that I'm not familiar with. Can someone help me understand if this is expected, and if so, why? If you write top secret data it should stay top secret even if you're writing to a folder that is normally reserved for secret data, or perhaps mixed data. Iirc it uses the MLS of the process when creating the file entry. -- Nick Kralevich | Android Security | nnk@google.com | 650.214.4037 _______________________________________________ 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. [-- Attachment #2: Type: text/html, Size: 3469 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MLS directory label inheritance rules 2017-04-07 18:39 MLS directory label inheritance rules Nick Kralevich 2017-04-07 18:51 ` William Roberts @ 2017-04-07 19:01 ` Dominick Grift 2017-04-07 19:41 ` Stephen Smalley 2 siblings, 0 replies; 9+ messages in thread From: Dominick Grift @ 2017-04-07 19:01 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 2926 bytes --] On Fri, Apr 07, 2017 at 11:39:55AM -0700, Nick Kralevich wrote: > When a file is created in a directory, the default label for the file > is based on the label of the enclosing directory (unless something > like setfscreatecon is used). For example: > > bullhead:/ # cd /data/misc/zoneinfo/ > > bullhead:/data/misc/zoneinfo # ls -ladZ . > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > 1971-06-19 17:07 . > bullhead:/data/misc/zoneinfo # touch asdf > bullhead:/data/misc/zoneinfo # ls -ladZ . asdf > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > 2017-04-07 18:32 . > -rw-rw-rw- 1 root root u:object_r:zoneinfo_data_file:s0 0 > 2017-04-07 18:32 asdf > > note how the label of the "asdf" file matches the label of the > enclosing directory. > > However, that's not true when the directory uses categories. In that > case, the newly created file inherits the label, but not the > categories. For example: > > bullhead:/data/data # cd /data/data/com.android.chrome > bullhead:/data/data/com.android.chrome # ls -ladZ . > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 4096 > 1971-07-15 15:31 . > bullhead:/data/data/com.android.chrome # touch asdf > bullhead:/data/data/com.android.chrome # ls -laZd . asdf > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 4096 > 2017-04-07 18:35 . > -rw-rw-rw- 1 root root u:object_r:app_data_file:s0 0 > 2017-04-07 18:35 asdf > > Note how the label is maintained, but the "c512,c768" portion is not > maintained. While this example occurs when I'm running in a permissive > domain, it also occurs in an enforcing domain. > > The inconsistency seems weird, and I'm sure there's a good reason why > this occurs that I'm not familiar with. Can someone help me understand > if this is expected, and if so, why? I think that is actually a sane default (defaultrange source) as opposed to default range target because if a process associated with s0:c123,c456 creates a file, then i would expect that file to inherit s0:c123,c456 from the source and not s0 from the target for example RedHat, i think, overrides this default as well and uses defaultrange target and I think that is a strange decision. If I have qemu instance with s0:c123,c456 that for example creates a pty, then I would want to have that pty constrained by s0:c123,c456 as well > > -- > Nick Kralevich | Android Security | nnk@google.com | 650.214.4037 > _______________________________________________ > 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. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MLS directory label inheritance rules 2017-04-07 18:39 MLS directory label inheritance rules Nick Kralevich 2017-04-07 18:51 ` William Roberts 2017-04-07 19:01 ` Dominick Grift @ 2017-04-07 19:41 ` Stephen Smalley 2017-04-07 19:58 ` Stephen Smalley 2 siblings, 1 reply; 9+ messages in thread From: Stephen Smalley @ 2017-04-07 19:41 UTC (permalink / raw) To: Nick Kralevich, SELinux On Fri, 2017-04-07 at 11:39 -0700, Nick Kralevich wrote: > When a file is created in a directory, the default label for the file > is based on the label of the enclosing directory (unless something > like setfscreatecon is used). For example: > > bullhead:/ # cd /data/misc/zoneinfo/ > > bullhead:/data/misc/zoneinfo # ls -ladZ . > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > 1971-06-19 17:07 . > bullhead:/data/misc/zoneinfo # touch asdf > bullhead:/data/misc/zoneinfo # ls -ladZ . asdf > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > 2017-04-07 18:32 . > -rw-rw-rw- 1 root root u:object_r:zoneinfo_data_file:s0 0 > 2017-04-07 18:32 asdf > > note how the label of the "asdf" file matches the label of the > enclosing directory. > > However, that's not true when the directory uses categories. In that > case, the newly created file inherits the label, but not the > categories. For example: > > bullhead:/data/data # cd /data/data/com.android.chrome > bullhead:/data/data/com.android.chrome # ls -ladZ . > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 4096 > 1971-07-15 15:31 . > bullhead:/data/data/com.android.chrome # touch asdf > bullhead:/data/data/com.android.chrome # ls -laZd . asdf > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 4096 > 2017-04-07 18:35 . > -rw-rw-rw- 1 root root u:object_r:app_data_file:s0 0 > 2017-04-07 18:35 asdf > > Note how the label is maintained, but the "c512,c768" portion is not > maintained. While this example occurs when I'm running in a > permissive > domain, it also occurs in an enforcing domain. > > The inconsistency seems weird, and I'm sure there's a good reason why > this occurs that I'm not familiar with. Can someone help me > understand > if this is expected, and if so, why? First, the good news is that you get to specify which behavior you want for each context field and object class through policy (as long as your kernel and policy version supports it), see: https://selinuxproject.org/page/DefaultRules Second, there are different defaults for each of the fields of the security contexts based on what is most normative for that particular security model. The user identity defaults to that of the creating process since we typically do not allow a process to create files with a different user identity and want the file to reflect its creator (this is defined through constraints on user identity in policies that define more than one, unlike Android). The role defaults to the fixed object_r role because originally we didn't envision a use case for roles on files. The MLS range defaults to the low/current level of the process because a process is typically not allowed to create files at a different level and we want the file to reflect the sensitivity of the data which originated from the process. The type defaults to a related object type (in this case that of the parent directory) because process domains and object types are separate (aside from overlapping use for /proc/pid) and the relationships among them are explicit through the TE rules / access matrix rather than through implicit rules. Of course, in addition to being able to globally configure the default behavior, you can also customize specific cases through the role/type/range_transition rules. With your example above, you wanted the file to inherit the level of the directory, but consider the situation where a process with categories (:s0:c512,c768) creates a file in some shared (mlstrustedobject) directory that is just :s0. Do you want that file to end up as just :s0? In the MLS world, that would be a downgrade / info leak. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MLS directory label inheritance rules 2017-04-07 19:41 ` Stephen Smalley @ 2017-04-07 19:58 ` Stephen Smalley 2017-04-07 20:15 ` Dennis Sherrell 0 siblings, 1 reply; 9+ messages in thread From: Stephen Smalley @ 2017-04-07 19:58 UTC (permalink / raw) To: Nick Kralevich, SELinux On Fri, 2017-04-07 at 15:41 -0400, Stephen Smalley wrote: > On Fri, 2017-04-07 at 11:39 -0700, Nick Kralevich wrote: > > When a file is created in a directory, the default label for the > > file > > is based on the label of the enclosing directory (unless something > > like setfscreatecon is used). For example: > > > > bullhead:/ # cd /data/misc/zoneinfo/ > > > > bullhead:/data/misc/zoneinfo # ls -ladZ . > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > > 1971-06-19 17:07 . > > bullhead:/data/misc/zoneinfo # touch asdf > > bullhead:/data/misc/zoneinfo # ls -ladZ . asdf > > > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > > 2017-04-07 18:32 . > > -rw-rw-rw- 1 root root u:object_r:zoneinfo_data_file:s0 0 > > 2017-04-07 18:32 asdf > > > > note how the label of the "asdf" file matches the label of the > > enclosing directory. > > > > However, that's not true when the directory uses categories. In > > that > > case, the newly created file inherits the label, but not the > > categories. For example: > > > > bullhead:/data/data # cd /data/data/com.android.chrome > > bullhead:/data/data/com.android.chrome # ls -ladZ . > > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 > > 4096 > > 1971-07-15 15:31 . > > bullhead:/data/data/com.android.chrome # touch asdf > > bullhead:/data/data/com.android.chrome # ls -laZd . asdf > > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 > > 4096 > > 2017-04-07 18:35 . > > -rw-rw-rw- 1 > > root root u:object_r:app_data_file:s0 0 > > 2017-04-07 18:35 asdf > > > > Note how the label is maintained, but the "c512,c768" portion is > > not > > maintained. While this example occurs when I'm running in a > > permissive > > domain, it also occurs in an enforcing domain. > > > > The inconsistency seems weird, and I'm sure there's a good reason > > why > > this occurs that I'm not familiar with. Can someone help me > > understand > > if this is expected, and if so, why? > > First, the good news is that you get to specify which behavior you > want > for each context field and object class through policy (as long as > your > kernel and policy version supports it), see: > https://selinuxproject.org/page/DefaultRules > > Second, there are different defaults for each of the fields of the > security contexts based on what is most normative for that particular > security model. The user identity defaults to that of the creating > process since we typically do not allow a process to create files > with > a different user identity and want the file to reflect its creator > (this is defined through constraints on user identity in policies > that > define more than one, unlike Android). The role defaults to the fixed > object_r role because originally we didn't envision a use case for > roles on files. The MLS range defaults to the low/current level of > the > process because a process is typically not allowed to create files at > a > different level and we want the file to reflect the sensitivity of > the > data which originated from the process. The type defaults to a > related > object type (in this case that of the parent directory) because > process > domains and object types are separate (aside from overlapping use for > /proc/pid) and the relationships among them are explicit through the > TE > rules / access matrix rather than through implicit rules. > > Of course, in addition to being able to globally configure the > default > behavior, you can also customize specific cases through the > role/type/range_transition rules. > > With your example above, you wanted the file to inherit the level of > the directory, but consider the situation where a process with > categories (:s0:c512,c768) creates a file in some shared > (mlstrustedobject) directory that is just :s0. Do you want that file > to end up as just :s0? In the MLS world, that would be a downgrade / > info leak. I guess that's not a great example since then the file would also end up with the same type by default and thus would be a mlstrustedobject and accessible regardless of its level. So you'd want a type transition to a derived type for files created in that directory to avoid that. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MLS directory label inheritance rules 2017-04-07 19:58 ` Stephen Smalley @ 2017-04-07 20:15 ` Dennis Sherrell 2017-04-07 20:19 ` Joshua Brindle ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Dennis Sherrell @ 2017-04-07 20:15 UTC (permalink / raw) To: Stephen Smalley, Nick Kralevich, SELinux [-- Attachment #1: Type: text/plain, Size: 5472 bytes --] In a thread ending with Nick Kravelich's contact infirmation, it was written: " If you write top secret data it should stay top secret even if you're writing to a folder that is normally reserved for secret data, or perhaps mixed data. Iirc it uses the MLS of the process when creating the file entry." I disagree. Top Secret data shoud not be written to a folder which was not provisioned for such. Allowing persons or processess of lower classification access to "containers" with higher clearance requirements could cause a data spill. Any thoughts as to active handling of such? Dennis Sherrell Sherrell Consulting Bakersfield, California Company #136601 Counter-Terrorism Cybernetic Countermeasure Developer On Fri, Apr 7, 2017, 12:55 PM Stephen Smalley <sds@tycho.nsa.gov> wrote: > On Fri, 2017-04-07 at 15:41 -0400, Stephen Smalley wrote: > > On Fri, 2017-04-07 at 11:39 -0700, Nick Kralevich wrote: > > > When a file is created in a directory, the default label for the > > > file > > > is based on the label of the enclosing directory (unless something > > > like setfscreatecon is used). For example: > > > > > > bullhead:/ # cd /data/misc/zoneinfo/ > > > > > > bullhead:/data/misc/zoneinfo # ls -ladZ . > > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > > > 1971-06-19 17:07 . > > > bullhead:/data/misc/zoneinfo # touch asdf > > > bullhead:/data/misc/zoneinfo # ls -ladZ . asdf > > > > > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > > > 2017-04-07 18:32 . > > > -rw-rw-rw- 1 root root u:object_r:zoneinfo_data_file:s0 0 > > > 2017-04-07 18:32 asdf > > > > > > note how the label of the "asdf" file matches the label of the > > > enclosing directory. > > > > > > However, that's not true when the directory uses categories. In > > > that > > > case, the newly created file inherits the label, but not the > > > categories. For example: > > > > > > bullhead:/data/data # cd /data/data/com.android.chrome > > > bullhead:/data/data/com.android.chrome # ls -ladZ . > > > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 > > > 4096 > > > 1971-07-15 15:31 . > > > bullhead:/data/data/com.android.chrome # touch asdf > > > bullhead:/data/data/com.android.chrome # ls -laZd . asdf > > > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 > > > 4096 > > > 2017-04-07 18:35 . > > > -rw-rw-rw- 1 > > > root root u:object_r:app_data_file:s0 0 > > > 2017-04-07 18:35 asdf > > > > > > Note how the label is maintained, but the "c512,c768" portion is > > > not > > > maintained. While this example occurs when I'm running in a > > > permissive > > > domain, it also occurs in an enforcing domain. > > > > > > The inconsistency seems weird, and I'm sure there's a good reason > > > why > > > this occurs that I'm not familiar with. Can someone help me > > > understand > > > if this is expected, and if so, why? > > > > First, the good news is that you get to specify which behavior you > > want > > for each context field and object class through policy (as long as > > your > > kernel and policy version supports it), see: > > https://selinuxproject.org/page/DefaultRules > > > > Second, there are different defaults for each of the fields of the > > security contexts based on what is most normative for that particular > > security model. The user identity defaults to that of the creating > > process since we typically do not allow a process to create files > > with > > a different user identity and want the file to reflect its creator > > (this is defined through constraints on user identity in policies > > that > > define more than one, unlike Android). The role defaults to the fixed > > object_r role because originally we didn't envision a use case for > > roles on files. The MLS range defaults to the low/current level of > > the > > process because a process is typically not allowed to create files at > > a > > different level and we want the file to reflect the sensitivity of > > the > > data which originated from the process. The type defaults to a > > related > > object type (in this case that of the parent directory) because > > process > > domains and object types are separate (aside from overlapping use for > > /proc/pid) and the relationships among them are explicit through the > > TE > > rules / access matrix rather than through implicit rules. > > > > Of course, in addition to being able to globally configure the > > default > > behavior, you can also customize specific cases through the > > role/type/range_transition rules. > > > > With your example above, you wanted the file to inherit the level of > > the directory, but consider the situation where a process with > > categories (:s0:c512,c768) creates a file in some shared > > (mlstrustedobject) directory that is just :s0. Do you want that file > > to end up as just :s0? In the MLS world, that would be a downgrade / > > info leak. > > I guess that's not a great example since then the file would also end > up with the same type by default and thus would be a mlstrustedobject > and accessible regardless of its level. So you'd want a type > transition to a derived type for files created in that directory to > avoid that. > > _______________________________________________ > 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. [-- Attachment #2: Type: text/html, Size: 8975 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MLS directory label inheritance rules 2017-04-07 20:15 ` Dennis Sherrell @ 2017-04-07 20:19 ` Joshua Brindle 2017-04-07 20:53 ` Casey Schaufler 2017-04-07 21:31 ` William Roberts 2 siblings, 0 replies; 9+ messages in thread From: Joshua Brindle @ 2017-04-07 20:19 UTC (permalink / raw) To: Dennis Sherrell; +Cc: Stephen Smalley, Nick Kralevich, SELinux Dennis Sherrell wrote: > In a thread ending with Nick Kravelich's contact infirmation, it was > written: > > " > If you write top secret data it should stay top secret even if you're > writing to a folder that is normally reserved for secret data, or perhaps > mixed data. Iirc it uses the MLS of the process when creating the file > entry." > > I disagree. Top Secret data shoud not be written to a folder which was not > provisioned for such. Allowing persons or processess of lower > classification access to "containers" with higher clearance requirements > could cause a data spill. Any thoughts as to active handling of such? > These are just the default labeling rules. The reading or writing would still need to be allowed by the TE policy and not removed by the constraints. MLS constraints should prevent a write from a TS subject to a S object regardless of what the default rule says the label should be. > Dennis Sherrell > Sherrell Consulting > Bakersfield, California Company #136601 > Counter-Terrorism > Cybernetic Countermeasure Developer > > On Fri, Apr 7, 2017, 12:55 PM Stephen Smalley<sds@tycho.nsa.gov> wrote: > >> On Fri, 2017-04-07 at 15:41 -0400, Stephen Smalley wrote: >>> On Fri, 2017-04-07 at 11:39 -0700, Nick Kralevich wrote: >>>> When a file is created in a directory, the default label for the >>>> file >>>> is based on the label of the enclosing directory (unless something >>>> like setfscreatecon is used). For example: >>>> >>>> bullhead:/ # cd /data/misc/zoneinfo/ >>>> >>>> bullhead:/data/misc/zoneinfo # ls -ladZ . >>>> drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 >>>> 1971-06-19 17:07 . >>>> bullhead:/data/misc/zoneinfo # touch asdf >>>> bullhead:/data/misc/zoneinfo # ls -ladZ . asdf >>>> >>>> drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 >>>> 2017-04-07 18:32 . >>>> -rw-rw-rw- 1 root root u:object_r:zoneinfo_data_file:s0 0 >>>> 2017-04-07 18:32 asdf >>>> >>>> note how the label of the "asdf" file matches the label of the >>>> enclosing directory. >>>> >>>> However, that's not true when the directory uses categories. In >>>> that >>>> case, the newly created file inherits the label, but not the >>>> categories. For example: >>>> >>>> bullhead:/data/data # cd /data/data/com.android.chrome >>>> bullhead:/data/data/com.android.chrome # ls -ladZ . >>>> drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 >>>> 4096 >>>> 1971-07-15 15:31 . >>>> bullhead:/data/data/com.android.chrome # touch asdf >>>> bullhead:/data/data/com.android.chrome # ls -laZd . asdf >>>> drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 >>>> 4096 >>>> 2017-04-07 18:35 . >>>> -rw-rw-rw- 1 >>>> root root u:object_r:app_data_file:s0 0 >>>> 2017-04-07 18:35 asdf >>>> >>>> Note how the label is maintained, but the "c512,c768" portion is >>>> not >>>> maintained. While this example occurs when I'm running in a >>>> permissive >>>> domain, it also occurs in an enforcing domain. >>>> >>>> The inconsistency seems weird, and I'm sure there's a good reason >>>> why >>>> this occurs that I'm not familiar with. Can someone help me >>>> understand >>>> if this is expected, and if so, why? >>> First, the good news is that you get to specify which behavior you >>> want >>> for each context field and object class through policy (as long as >>> your >>> kernel and policy version supports it), see: >>> https://selinuxproject.org/page/DefaultRules >>> >>> Second, there are different defaults for each of the fields of the >>> security contexts based on what is most normative for that particular >>> security model. The user identity defaults to that of the creating >>> process since we typically do not allow a process to create files >>> with >>> a different user identity and want the file to reflect its creator >>> (this is defined through constraints on user identity in policies >>> that >>> define more than one, unlike Android). The role defaults to the fixed >>> object_r role because originally we didn't envision a use case for >>> roles on files. The MLS range defaults to the low/current level of >>> the >>> process because a process is typically not allowed to create files at >>> a >>> different level and we want the file to reflect the sensitivity of >>> the >>> data which originated from the process. The type defaults to a >>> related >>> object type (in this case that of the parent directory) because >>> process >>> domains and object types are separate (aside from overlapping use for >>> /proc/pid) and the relationships among them are explicit through the >>> TE >>> rules / access matrix rather than through implicit rules. >>> >>> Of course, in addition to being able to globally configure the >>> default >>> behavior, you can also customize specific cases through the >>> role/type/range_transition rules. >>> >>> With your example above, you wanted the file to inherit the level of >>> the directory, but consider the situation where a process with >>> categories (:s0:c512,c768) creates a file in some shared >>> (mlstrustedobject) directory that is just :s0. Do you want that file >>> to end up as just :s0? In the MLS world, that would be a downgrade / >>> info leak. >> I guess that's not a great example since then the file would also end >> up with the same type by default and thus would be a mlstrustedobject >> and accessible regardless of its level. So you'd want a type >> transition to a derived type for files created in that directory to >> avoid that. >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MLS directory label inheritance rules 2017-04-07 20:15 ` Dennis Sherrell 2017-04-07 20:19 ` Joshua Brindle @ 2017-04-07 20:53 ` Casey Schaufler 2017-04-07 21:31 ` William Roberts 2 siblings, 0 replies; 9+ messages in thread From: Casey Schaufler @ 2017-04-07 20:53 UTC (permalink / raw) To: Dennis Sherrell, Stephen Smalley, Nick Kralevich, SELinux [-- Attachment #1: Type: text/plain, Size: 6973 bytes --] On 4/7/2017 1:15 PM, Dennis Sherrell wrote: > > In a thread ending with Nick Kravelich's contact infirmation, it was written: > > " > If you write top secret data it should stay top secret even if you're writing to a folder that is normally reserved for secret data, or perhaps mixed data. Iirc it uses the MLS of the process when creating the file entry." > > I disagree. Top Secret data shoud not be written to a folder which was not provisioned for such. Allowing persons or processess of lower classification access to "containers" with higher clearance requirements could cause a data spill. Any thoughts as to active handling of such? > If you can only put TS objects in TS directories where do you put the first TS directory? While it is generally true that you don't want to put TS things in places that uncleared subjects can't see them, you have to allow for the exception of a TS directory in a less than TS directory. Otherwise you can only have single-level filesystems. We ran into this question way back in the Orange Book era. Although there were several "clever" ideas put forth, the model of allowing higher level objects to be created in lower level directories *under controlled circumstances* was gradually adopted as the only viable option. > Dennis Sherrell > Sherrell Consulting > Bakersfield, California Company #136601 > Counter-Terrorism > Cybernetic Countermeasure Developer > > > On Fri, Apr 7, 2017, 12:55 PM Stephen Smalley <sds@tycho.nsa.gov <mailto:sds@tycho.nsa.gov>> wrote: > > On Fri, 2017-04-07 at 15:41 -0400, Stephen Smalley wrote: > > On Fri, 2017-04-07 at 11:39 -0700, Nick Kralevich wrote: > > > When a file is created in a directory, the default label for the > > > file > > > is based on the label of the enclosing directory (unless something > > > like setfscreatecon is used). For example: > > > > > > bullhead:/ # cd /data/misc/zoneinfo/ > > > > > > bullhead:/data/misc/zoneinfo # ls -ladZ . > > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > > > 1971-06-19 17:07 . > > > bullhead:/data/misc/zoneinfo # touch asdf > > > bullhead:/data/misc/zoneinfo # ls -ladZ . asdf > > > > > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > > > 2017-04-07 18:32 . > > > -rw-rw-rw- 1 root root u:object_r:zoneinfo_data_file:s0 0 > > > 2017-04-07 18:32 asdf > > > > > > note how the label of the "asdf" file matches the label of the > > > enclosing directory. > > > > > > However, that's not true when the directory uses categories. In > > > that > > > case, the newly created file inherits the label, but not the > > > categories. For example: > > > > > > bullhead:/data/data # cd /data/data/com.android.chrome > > > bullhead:/data/data/com.android.chrome # ls -ladZ . > > > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 > > > 4096 > > > 1971-07-15 15:31 . > > > bullhead:/data/data/com.android.chrome # touch asdf > > > bullhead:/data/data/com.android.chrome # ls -laZd . asdf > > > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 > > > 4096 > > > 2017-04-07 18:35 . > > > -rw-rw-rw- 1 > > > root root u:object_r:app_data_file:s0 0 > > > 2017-04-07 18:35 asdf > > > > > > Note how the label is maintained, but the "c512,c768" portion is > > > not > > > maintained. While this example occurs when I'm running in a > > > permissive > > > domain, it also occurs in an enforcing domain. > > > > > > The inconsistency seems weird, and I'm sure there's a good reason > > > why > > > this occurs that I'm not familiar with. Can someone help me > > > understand > > > if this is expected, and if so, why? > > > > First, the good news is that you get to specify which behavior you > > want > > for each context field and object class through policy (as long as > > your > > kernel and policy version supports it), see: > > https://selinuxproject.org/page/DefaultRules > > > > Second, there are different defaults for each of the fields of the > > security contexts based on what is most normative for that particular > > security model. The user identity defaults to that of the creating > > process since we typically do not allow a process to create files > > with > > a different user identity and want the file to reflect its creator > > (this is defined through constraints on user identity in policies > > that > > define more than one, unlike Android). The role defaults to the fixed > > object_r role because originally we didn't envision a use case for > > roles on files. The MLS range defaults to the low/current level of > > the > > process because a process is typically not allowed to create files at > > a > > different level and we want the file to reflect the sensitivity of > > the > > data which originated from the process. The type defaults to a > > related > > object type (in this case that of the parent directory) because > > process > > domains and object types are separate (aside from overlapping use for > > /proc/pid) and the relationships among them are explicit through the > > TE > > rules / access matrix rather than through implicit rules. > > > > Of course, in addition to being able to globally configure the > > default > > behavior, you can also customize specific cases through the > > role/type/range_transition rules. > > > > With your example above, you wanted the file to inherit the level of > > the directory, but consider the situation where a process with > > categories (:s0:c512,c768) creates a file in some shared > > (mlstrustedobject) directory that is just :s0. Do you want that file > > to end up as just :s0? In the MLS world, that would be a downgrade / > > info leak. > > I guess that's not a great example since then the file would also end > up with the same type by default and thus would be a mlstrustedobject > and accessible regardless of its level. So you'd want a type > transition to a derived type for files created in that directory to > avoid that. > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov <mailto:Selinux@tycho.nsa.gov> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov <mailto:Selinux-leave@tycho.nsa.gov>. > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov <mailto:Selinux-request@tycho.nsa.gov>. > > > > _______________________________________________ > 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. [-- Attachment #2: Type: text/html, Size: 12956 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MLS directory label inheritance rules 2017-04-07 20:15 ` Dennis Sherrell 2017-04-07 20:19 ` Joshua Brindle 2017-04-07 20:53 ` Casey Schaufler @ 2017-04-07 21:31 ` William Roberts 2 siblings, 0 replies; 9+ messages in thread From: William Roberts @ 2017-04-07 21:31 UTC (permalink / raw) To: Dennis Sherrell; +Cc: selinux, Stephen Smalley, Nick Kralevich [-- Attachment #1: Type: text/plain, Size: 5978 bytes --] On Apr 7, 2017 13:16, "Dennis Sherrell" <sherrellconsulting@gmail.com> wrote: In a thread ending with Nick Kravelich's contact infirmation, it was written: " If you write top secret data it should stay top secret even if you're writing to a folder that is normally reserved for secret data, or perhaps mixed data. Iirc it uses the MLS of the process when creating the file entry." I disagree. Top Secret data shoud not be written to a folder which was not provisioned for such. You guys are too nuanced at times, it was meant to be a very simple contrived answer without typing a long diatribe. In general Stephens shared tmp example is in essence what I was going for. Allowing persons or processess of lower classification access to "containers" with higher clearance requirements could cause a data spill. Any thoughts as to active handling of such? Dennis Sherrell Sherrell Consulting Bakersfield, California Company #136601 Counter-Terrorism Cybernetic Countermeasure Developer On Fri, Apr 7, 2017, 12:55 PM Stephen Smalley <sds@tycho.nsa.gov> wrote: > On Fri, 2017-04-07 at 15:41 -0400, Stephen Smalley wrote: > > On Fri, 2017-04-07 at 11:39 -0700, Nick Kralevich wrote: > > > When a file is created in a directory, the default label for the > > > file > > > is based on the label of the enclosing directory (unless something > > > like setfscreatecon is used). For example: > > > > > > bullhead:/ # cd /data/misc/zoneinfo/ > > > > > > bullhead:/data/misc/zoneinfo # ls -ladZ . > > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > > > 1971-06-19 17:07 . > > > bullhead:/data/misc/zoneinfo # touch asdf > > > bullhead:/data/misc/zoneinfo # ls -ladZ . asdf > > > > > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > > > 2017-04-07 18:32 . > > > -rw-rw-rw- 1 root root u:object_r:zoneinfo_data_file:s0 0 > > > 2017-04-07 18:32 asdf > > > > > > note how the label of the "asdf" file matches the label of the > > > enclosing directory. > > > > > > However, that's not true when the directory uses categories. In > > > that > > > case, the newly created file inherits the label, but not the > > > categories. For example: > > > > > > bullhead:/data/data # cd /data/data/com.android.chrome > > > bullhead:/data/data/com.android.chrome # ls -ladZ . > > > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 > > > 4096 > > > 1971-07-15 15:31 . > > > bullhead:/data/data/com.android.chrome # touch asdf > > > bullhead:/data/data/com.android.chrome # ls -laZd . asdf > > > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 > > > 4096 > > > 2017-04-07 18:35 . > > > -rw-rw-rw- 1 > > > root root u:object_r:app_data_file:s0 0 > > > 2017-04-07 18:35 asdf > > > > > > Note how the label is maintained, but the "c512,c768" portion is > > > not > > > maintained. While this example occurs when I'm running in a > > > permissive > > > domain, it also occurs in an enforcing domain. > > > > > > The inconsistency seems weird, and I'm sure there's a good reason > > > why > > > this occurs that I'm not familiar with. Can someone help me > > > understand > > > if this is expected, and if so, why? > > > > First, the good news is that you get to specify which behavior you > > want > > for each context field and object class through policy (as long as > > your > > kernel and policy version supports it), see: > > https://selinuxproject.org/page/DefaultRules > > > > Second, there are different defaults for each of the fields of the > > security contexts based on what is most normative for that particular > > security model. The user identity defaults to that of the creating > > process since we typically do not allow a process to create files > > with > > a different user identity and want the file to reflect its creator > > (this is defined through constraints on user identity in policies > > that > > define more than one, unlike Android). The role defaults to the fixed > > object_r role because originally we didn't envision a use case for > > roles on files. The MLS range defaults to the low/current level of > > the > > process because a process is typically not allowed to create files at > > a > > different level and we want the file to reflect the sensitivity of > > the > > data which originated from the process. The type defaults to a > > related > > object type (in this case that of the parent directory) because > > process > > domains and object types are separate (aside from overlapping use for > > /proc/pid) and the relationships among them are explicit through the > > TE > > rules / access matrix rather than through implicit rules. > > > > Of course, in addition to being able to globally configure the > > default > > behavior, you can also customize specific cases through the > > role/type/range_transition rules. > > > > With your example above, you wanted the file to inherit the level of > > the directory, but consider the situation where a process with > > categories (:s0:c512,c768) creates a file in some shared > > (mlstrustedobject) directory that is just :s0. Do you want that file > > to end up as just :s0? In the MLS world, that would be a downgrade / > > info leak. > > I guess that's not a great example since then the file would also end > up with the same type by default and thus would be a mlstrustedobject > and accessible regardless of its level. So you'd want a type > transition to a derived type for files created in that directory to > avoid that. > > _______________________________________________ > 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. _______________________________________________ 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. [-- Attachment #2: Type: text/html, Size: 12902 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-04-07 21:31 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-07 18:39 MLS directory label inheritance rules Nick Kralevich 2017-04-07 18:51 ` William Roberts 2017-04-07 19:01 ` Dominick Grift 2017-04-07 19:41 ` Stephen Smalley 2017-04-07 19:58 ` Stephen Smalley 2017-04-07 20:15 ` Dennis Sherrell 2017-04-07 20:19 ` Joshua Brindle 2017-04-07 20:53 ` Casey Schaufler 2017-04-07 21:31 ` William Roberts
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.