[redhat-lspp] userdomain policy question ..

[Janak Desai]

On Mon, 2006-08-07 at 16:14 -0400, Stephen Smalley wrote:
> On Mon, 2006-08-07 at 11:02 -0400, Janak Desai wrote:
> > The current strict-mls policy allows all user domains to modify
> > their own /proc/self/attr/fscreate file because of the following
> > line in base_user_template of userdomain.if
> > 
> >   allow $1_t self:process { ptrace setfscreate };
> > 
> > I know that does not mean a user can create files with any 
> > desired context, because the policy will apply restrictions
> > at the file creation time. However, I was wondering why 
> > unprivileged user domains need the ability to update their
> > /proc/self/attr/fscreate file. From evaluation perspective,
> > fscreate file is a security relevant file, whose modification
> > is supposed to be restricted and audited. Any ideas?
> 
> Being able to create an object with a particular context is no more
> security relevant (actually less) than being able to relabel an object,
> so I presume you are applying the same scrutiny to setxattr calls
> (=>relabelfrom/relabelto)?
> 

Yes, we do. We test setxattr calls and also relabelfrom/relabelto
permissions and their interaction with setfscreatecon. 

> In the TE policy, there is a set of types that can be applied
> selectively by the user to his home directory files, and to which he
> therefore often has create and relabelfrom/relabelto permissions, e.g.
> user_fonts_config_t or httpd_user_script_rw_t.
> 

Ok, thanks. Now I understand why you would want to allow a user
process access to their own fscreate file.

> fscreate isn't a real file; it is just a kernel interface for setting an
> attribute of the process, like calling umask(2) to set the file mode
> creation mask.
> 

Good point. Just like we test (and audit) the use of umask system call,
we will have to audit the use of setfscreatecon. 

Klaus, would it be sufficient, for meeting LSPP requirement, to
audit write(2) of the fscreate file?

-Janak