Tomcat policy

Tomcat policy

[Nick Gray]

I have written a policy for Tomcat that works. And surprise it actually
works (on my development system) If anyone is interested, I can post it
up to the list after giving myself a chance to smooth it out a bit.

I have a few questions. regarding policies in general and how they
applied to my case in point.


#1

The installation of tree for tomcat looks something like 

/usr/local/tomcat/5.0.28 
/usr/local/tomcat/5.0.28/conf
/usr/local/tomcat/5.0.28/logs
/usr/local/tomcat/5.0.28/...

I also defined

daemon_domain(tomcat)
type tomcat_config_t, file_type, sysadmfile;
type tomcat_log_t, file_type, sysadmfile;

If I am correct in my assumption that the "daemon_domain(tomcat)"
defines the tomcat_t type, I thought I could do the following in
the tomcat.fc

/usr/local/tomcat/5.0.28/logs(/.*)?    system_u:object_r:tomcat_log_t
/usr/local/tomcat/5.0.28/conf(/.*)?    system_u:object_r:tomcat_config_t
# This does not work ??
#/usr/local/tomcat/5.0.28(/.*)?         system_u:object_r:tomcat_t

The logs and conf work like I thought, but when the system trys to label
the others it gets permission denied. I don't believe it is a permision
problem since I accidentally tried this and it worked

/usr/local/tomcat/5.0.28(/.*)?    system_u:object_r:tomcat_log_t

So why can't I use tomcat_t to label directories?


#2

I think I understand how to protect the daemon from the system, how do I
protect the system from the daemon.

The example I can come up with is a jsp page that opens
the /etc/passwd/file and prints it. I want to keep the tomcat process
encapsulated in it own space

It seems I would want a restricted user "tomcat"! Since daemon does a
check that it is being started by the unix user "tomcat", a natural
extension of this would be to ensure that the user process has no access
to the system other than what I have determined,


Thanks

-- 

Nick Gray
Senior Systems Engineer
Bruzenak Inc
Office: 512-331-7998
Cell: 512-630-7009

--
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.

Re: Tomcat policy

[Stephen Smalley]

On Thu, 2004-12-16 at 14:08, Nick Gray wrote:
> So why can't I use tomcat_t to label directories?

Because you have defined it as a domain, not a file type.  Domains are
for processes, and are also applied to the /proc/pid entries of that
process.  You aren't supposed to use them for other files, and the
filesystem associate permission check enforces the restriction.

You do need to label the entrypoint program for the daemon with
tomcat_exec_t.

> I think I understand how to protect the daemon from the system, how do I
> protect the system from the daemon.

Under targeted policy, the "system" (i.e. unconfined processes) can do
whatever it wants to the daemon.  By defining a domain for tomcat, you
are merely controlling what it can do to the system, and isolating it
from other confined domains.  The daemon (if you have set it up properly
to run in the tomcat_t domain) can only do what you allow tomcat_t to do
in the policy, nothing else.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: Tomcat policy

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Thu, 2004-12-16 at 13:08 -0600, Nick Gray wrote:

> #/usr/local/tomcat/5.0.28(/.*)?         system_u:object_r:tomcat_t

You want tomcat_exec_t.

> I think I understand how to protect the daemon from the system, how do I
> protect the system from the daemon.
> 
> The example I can come up with is a jsp page that opens
> the /etc/passwd/file and prints it. I want to keep the tomcat process
> encapsulated in it own space

Simply don't allow tomcat_t access to passwd_t.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Tomcat policy

[Stephen Smalley]

On Thu, 2004-12-16 at 16:39, Colin Walters wrote:
> Simply don't allow tomcat_t access to passwd_t.

No permissions to etc_t:file if we are talking about /etc/passwd.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: Tomcat policy

[Nick Gray]

On Thu, 2004-12-16 at 15:46 -0500, Stephen Smalley wrote:
> On Thu, 2004-12-16 at 14:08, Nick Gray wrote:
> > So why can't I use tomcat_t to label directories?
> 
> Because you have defined it as a domain, not a file type.  Domains are
> for processes, and are also applied to the /proc/pid entries of that
> process.  You aren't supposed to use them for other files, and the
> filesystem associate permission check enforces the restriction.
> 
> You do need to label the entrypoint program for the daemon with
> tomcat_exec_t.

This was done, I just didn't spell it out.

tomcat_exec_t would be for the actual executable binaries right. I am
talking about a default label for the entire directory structure
starting with /usr/local/tomcat/. That in the strict policy would keep
all other users out of this subdirectory.

> 
> > I think I understand how to protect the daemon from the system, how do I
> > protect the system from the daemon.
> 
> Under targeted policy, the "system" (i.e. unconfined processes) can do
> whatever it wants to the daemon. 

So basically, your saying I haven't even done what I thought I did. That
if I create a user, by default he will be unconfined and can get into
the labeled tomcat directories depending on the unix permissions?

>  By defining a domain for tomcat, you
> are merely controlling what it can do to the system, 

Sounds like you are telling me that the tomcat daemon can't access types
outside its domain such as unconfined_t.

> and isolating it
> from other confined domains.

This makes sense since tomcat_t shouldn't be able to access httpd_t

>   The daemon (if you have set it up properly
> to run in the tomcat_t domain) can only do what you allow tomcat_t to do
> in the policy, nothing else.

the tomcat (jsvc) application is running as user_u:system_r:tomcat_t. 


> Simply don't allow tomcat_t access to passwd_t.

This isn't a very robust solution since this is one case in point. It
seems to (I'm sure you'll correct me on this point) that the optimum
solution is to add the tomcat user to the user.te file with a role like
user_r and or creating a tomcat_r and giving it access only to the
tomcat domain.

By doing the above, would'nt we have accomplished (in the most efficient
manner) the securing of the tomcat daemon. If a buffer overflow happens
which gives the tomcat user (by virtue of the user that the daemon is
running as) root access, the tomcat user is restricted to the tomcat
domain and prevent from doing much more than creating logs
in /usr/local/tomcat/.../logs, as per the policy!




--
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.

Re: Tomcat policy

[Stephen Smalley]

On Fri, 2004-12-17 at 09:56, Nick Gray wrote:
> tomcat_exec_t would be for the actual executable binaries right. I am
> talking about a default label for the entire directory structure
> starting with /usr/local/tomcat/. That in the strict policy would keep
> all other users out of this subdirectory.

Ok, so you need a different type for that purpose, e.g. 
type tomcat_files_t, file_type, sysadmfile;

> So basically, your saying I haven't even done what I thought I did. That
> if I create a user, by default he will be unconfined and can get into
> the labeled tomcat directories depending on the unix permissions?

Targeted policy doesn't confine user sessions, just particular daemons. 
Strict policy confines user sessions, user programs, and daemons.

> Sounds like you are telling me that the tomcat daemon can't access types
> outside its domain such as unconfined_t.

Right, or any file types that it isn't explicitly allowed to access in
your tomcat policy.

> This isn't a very robust solution since this is one case in point. It
> seems to (I'm sure you'll correct me on this point) that the optimum
> solution is to add the tomcat user to the user.te file with a role like
> user_r and or creating a tomcat_r and giving it access only to the
> tomcat domain.

I don't understand why the isolation provided by the domain isn't
sufficient.  SELinux users and roles are for real users, not daemons.

> By doing the above, would'nt we have accomplished (in the most efficient
> manner) the securing of the tomcat daemon. If a buffer overflow happens
> which gives the tomcat user (by virtue of the user that the daemon is
> running as) root access, the tomcat user is restricted to the tomcat
> domain and prevent from doing much more than creating logs
> in /usr/local/tomcat/.../logs, as per the policy!

If you start the daemon in tomcat_t, then it can't transition to any
other domains other than what you allow in the policy via
domain_auto_trans rules.  And it cannot access any types other than what
you allow in the policy.  So it is already bounded in its potential
privilege escalation to what you define, without introducing fake users
into the equation.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: Tomcat policy

[Nick Gray]

On Fri, 2004-12-17 at 10:09 -0500, Stephen Smalley wrote:
> On Fri, 2004-12-17 at 09:56, Nick Gray wrote:
> > tomcat_exec_t would be for the actual executable binaries right. I am
> > talking about a default label for the entire directory structure
> > starting with /usr/local/tomcat/. That in the strict policy would keep
> > all other users out of this subdirectory.
> 
> Ok, so you need a different type for that purpose, e.g. 
> type tomcat_files_t, file_type, sysadmfile;

Got it! I will create that and give it a try.

> 
> > So basically, your saying I haven't even done what I thought I did. That
> > if I create a user, by default he will be unconfined and can get into
> > the labeled tomcat directories depending on the unix permissions?
> 
> Targeted policy doesn't confine user sessions, just particular daemons. 
> Strict policy confines user sessions, user programs, and daemons.

OK

> > Sounds like you are telling me that the tomcat daemon can't access types
> > outside its domain such as unconfined_t.

See below

> Right, or any file types that it isn't explicitly allowed to access in
> your tomcat policy.
> 
> > This isn't a very robust solution since this is one case in point. It
> > seems to (I'm sure you'll correct me on this point) that the optimum
> > solution is to add the tomcat user to the user.te file with a role like
> > user_r and or creating a tomcat_r and giving it access only to the
> > tomcat domain.
> 
> I don't understand why the isolation provided by the domain isn't
> sufficient.  SELinux users and roles are for real users, not daemons.

Always the cynic, I am having trouble believing that the daemon can't
get access to other aspects of the system. I will test this out today.
If so then this point becomes mute. Thanks! 

> > By doing the above, would'nt we have accomplished (in the most efficient
> > manner) the securing of the tomcat daemon. If a buffer overflow happens
> > which gives the tomcat user (by virtue of the user that the daemon is
> > running as) root access, the tomcat user is restricted to the tomcat
> > domain and prevent from doing much more than creating logs
> > in /usr/local/tomcat/.../logs, as per the policy!
> 
> If you start the daemon in tomcat_t, then it can't transition to any
> other domains other than what you allow in the policy via
> domain_auto_trans rules.  And it cannot access any types other than what
> you allow in the policy.  So it is already bounded in its potential
> privilege escalation to what you define, without introducing fake users
> into the equation.

Same as above

--
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.