Questions about Apache and SELinux context inheritance

[Christofer C. Bell]

I have a question about how context inheritance works in SELinux.

The correct file context is already defined in
/etc/selinux/targeted/contexts/files/file_contexts as:

/home/[^/]+/((www)|(web)|(public_html))(/.+)?
system_u:object_r:httpd_user_content_t

However, this context is not inherited when creating a public_html
directory as a user or as root in a user home directory.  In
otherwords, when creating a public_html directory, this is what you
get:

drwxrwxr-x  cbell    cbell    user_u:object_r:user_home_t      public_html

(I must admit some confusion about the initial user_u user context
since this is not defined in file_contexts).  Here you see that the
user context is set to user_u, the role is set to object_r, and the
type is set to user_home_t.  This is (in)correctly inherited from the
/home directory's context.

Simply running restorecon -v -R /home/ (as a user or root)  will fix
it to read thusly:

drwxrwxr-x  cbell    cbell    system_u:object_r:httpd_user_content_t public_html

At anyrate, the user label is correctly set to system_u, the role is
unchanged with object_r, and the type is changed to
http_user_content_t.  This is the context I'd like public_html
directories to automatically assume when created.  Is this possible?

Further puzzles:

When creating files in this public_html directory (after resetting the
directory to the correct context) yields more puzzling results:

[cbell@circe public_html]$ touch test
[cbell@circe public_html]$ ls -Z
-rw-rw-r--  cbell    cbell    user_u:object_r:httpd_sys_content_t test

Note that in this case, the file has been set to user context user_u,
role object_r, and type httpd_sys_content_t.  This is the type that's
supposedly reserved for the machine's public web directories:

(from file_contexts)
/var/www(/.*)?                  system_u:object_r:httpd_sys_content_t

Again, one must run restorecon to correctly set the context on this file to:

-rw-rw-r--  cbell    cbell    system_u:object_r:httpd_user_content_t test

So my questions are fourfold:

o How can one cause the correct httpd_user_content_t type to be
automatically assigned to user public_html directories (and
subdirectories)?

o How can one cause the correct httpd_user_content_t type to be
automatically assigned to user content (files) in user public_html
directores?

o Why are files initially receiving a user context of user_u rather
than system_u ?

And one file, slightly unrelated question:

o When I installed this server and restored user data to it, the user
context on all the files was set to root rather than user_u (and why
not system_u?).  I've reset everything to the correct user context
with chcon, but I'd like to know why this happened.

Thank you all for your insight!

-- 
Chris

"Build a man a fire and he will be warm for the rest of the night.  Set
a man on fire and he will be warm for the rest of his life."  -- Unknown

[Ivan Gyurdiev]

>  So my questions are fourfold:
>  
>  o How can one cause the correct httpd_user_content_t type to be
>  automatically assigned to user public_html directories (and
>  subdirectories)? 
Not possible. Put the folder in /etc/skel with the correct context.
Maybe this should be done by default in Fedora, or maybe not.
>  
>  o How can one cause the correct httpd_user_content_t type to be
>  automatically assigned to user content (files) in user public_html
>  directores? 
Possible w/ file_type_auto_trans rule. 
Will investigate...

>  o Why are files initially receiving a user context of user_u rather
>  than system_u ? 
This is normal - the user part of the context is set to the user who
created the file - no problem here.

>  And one file, slightly unrelated question:
>  
>  o When I installed this server and restored user data to it, the user
>  context on all the files was set to root rather than user_u (and why
>  not system_u?).  I've reset everything to the correct user context
>  with chcon, but I'd like to know why this happened. 
Because you restored the context as root, probably.
The user is set to whoever operates on the file.

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Daniel J Walsh]

Ivan Gyurdiev wrote:

> >So my questions are fourfold:
> >
> >o How can one cause the correct httpd_user_content_t type to be
> >automatically assigned to user public_html directories (and
> >subdirectories)?
> >    
> >
>
> Not possible. Put the folder in /etc/skel with the correct context.
> Maybe this should be done by default in Fedora, or maybe not.
>   
>
> >o How can one cause the correct httpd_user_content_t type to be
> >automatically assigned to user content (files) in user public_html
> >directores?
> >    
> >
>
> Possible w/ file_type_auto_trans rule. 
> Will investigate...
>
>   
>
> >o Why are files initially receiving a user context of user_u rather
> >than system_u ?
> >    
> >
>
> This is normal - the user part of the context is set to the user who
> created the file - no problem here.
>
>   
>
> >And one file, slightly unrelated question:
> >
> >o When I installed this server and restored user data to it, the user
> >context on all the files was set to root rather than user_u (and why
> >not system_u?).  I've reset everything to the correct user context
> >with chcon, but I'd like to know why this happened.
> >    
> >
>
> Because you restored the context as root, probably.
> The user is set to whoever operates on the file.
>
>   
>  
Adduser in rawhide and test1 now creates files with the "right" context 
when it creates the skel.

So if you put a public_html directory in /etc/skel.  It should get 
created with the correct context.

Dan

--

[Colin Walters]

I assume you're running the strict policy here; in the future please
state explicitly what Fedora release and policy you're using.

On Sat, 2005-03-12 at 18:46 -0600, Christofer C. Bell wrote:

>  However, this context is not inherited when creating a public_html
>  directory as a user or as root in a user home directory.  In
>  otherwords, when creating a public_html directory, this is what you
>  get:
>  
>  drwxrwxr-x  cbell    cbell    user_u:object_r:user_home_t      public_html 
Security contexts are not typically assigned based on filenames after
system initialization.  In other words, if you use 'mkdir', the GNOME
file manager, or whatever to create a file, it will have a context
assigned to it based solely on the security context of its parent
directory.  

You can however later use a command such as "restorecon" to change the
security context of a file based on its name.  Or you can use "chcon" to
assign contexts directly regardless of file name.

>  (I must admit some confusion about the initial user_u user context
>  since this is not defined in file_contexts).  
It's debatable whether it should be system_u or user_u; the user
identity component of the security context has a few purposes.  One is
to identify the creator of an object.  If the system created it, then
logically the user is system_u.  But it's also used in the constraints,
for example to ensure a process can't relabel a file with a differing
user identity.  If you want to allow a user that privilege, the user
identity needs to be user_u.

Probably by default all files in the user's home directory should be
user_u (or staff_u).

>  At anyrate, the user label is correctly set to system_u, the role is
>  unchanged with object_r, and the type is changed to
>  http_user_content_t.  This is the context I'd like public_html
>  directories to automatically assume when created.  Is this possible?
>   
Not really.  An explicit decision was made to not assign contexts based
on filenames after system initialization inside the kernel ("mkdir",
"open", etc).  Instead, one should modify the system to assign them
correctly.  In this case we probably should have public_html
in /etc/skel as Ivan suggested.  Or something similar.

>  Further puzzles:
>  
>  When creating files in this public_html directory (after resetting the
>  directory to the correct context) yields more puzzling results:
>  
>  [cbell@circe public_html]$ touch test
>  [cbell@circe public_html]$ ls -Z
>  -rw-rw-r--  cbell    cbell    user_u:object_r:httpd_sys_content_t test 
Right; if the directory has type httpd_sys_content_t, any files created
inside it will inherit that type.

>  Note that in this case, the file has been set to user context
> user_u,
>  role object_r, and type httpd_sys_content_t.  This is the type that's
>  supposedly reserved for the machine's public web directories: 
Indeed.

>  o How can one cause the correct httpd_user_content_t type to be
>  automatically assigned to user public_html directories (and
>  subdirectories)? 
This sounds like a recent bug introduced in the strict policy.  

>  o How can one cause the correct httpd_user_content_t type to be
>  automatically assigned to user content (files) in user public_html
>  directores? 
That will happen automatically when the directory has that type.

>  o Why are files initially receiving a user context of user_u rather
>  than system_u ? 
When they're created after system initalization?  Because the user
identity is derived from the identity of the creating process.

>  o When I installed this server and restored user data to it, the
> user
>  context on all the files was set to root rather than user_u (and why
>  not system_u?).  I've reset everything to the correct user context
>  with chcon, but I'd like to know why this happened. 
Presumably you untarred (or whatever) the data as root:sysadm_r?  In
that case the files again by default inherit the user identity of the
creating process.  For restoring data, you should use a tool that
preserves security contexts.

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide...

Also rsync in rawhide has a -X option.

[Colin Walters]

On Sat, 2005-03-12 at 18:46 -0600, Christofer C. Bell wrote:
>  I have a question about how context inheritance works in SELinux.
>  
>  The correct file context is already defined in
>  /etc/selinux/targeted/contexts/files/file_contexts as: 
Ah, sorry, so you are running targeted policy.  With all your discussion
of users I had assumed it was strict.

One thing that might explain a lot then is that httpd_sys_content_t and
httpd_user_content_t are exactly the same thing in the targeted policy:

domains/program/apache.te:
ifdef(`targeted_policy', `
typealias httpd_sys_content_t alias httpd_user_content_t;
typealias httpd_sys_script_exec_t alias httpd_user_script_exec_t;