From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1491595109.20167.6.camel@tycho.nsa.gov> Subject: Re: MLS directory label inheritance rules From: Stephen Smalley To: Nick Kralevich , SELinux Date: Fri, 07 Apr 2017 15:58:29 -0400 In-Reply-To: <1491594062.20167.4.camel@tycho.nsa.gov> References: <1491594062.20167.4.camel@tycho.nsa.gov> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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.