Squid policy for SE Linux

Squid policy for SE Linux

[Russell Coker]

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

I have attached my squid.te file.

Here's the relevant parts of my file_contexts file:
/var/cache/squid(|/.*)          system_u:object_r:httpd_cache_t
/usr/lib/squid                  system_u:object_r:squid_t
/usr/sbin/squid                 system_u:object_r:squid_exec_t
/var/log/squid                  system_u:object_r:var_log_squid_t

I also added squid_t to system_r in the rbac file.

I also had to make a couple of minor changes to the squid start script 
(hacked Debian start script attached).

Firstly I made the script change the uid/gid of squid because I didn't want 
to grant setuid capability to the squid binary.

Then I changed the script to do a "cd /" before starting squid instead of
"cd /var/cache/squid" because the /var/cache/squid directory is not readable 
by the initrc_t domain.

Please let me know of any suggestions for improvements.  NSA People, please 
include this in the sample policy if it's good enough.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

[-- Attachment #2: squid.te --]
[-- Type: text/plain, Size: 1366 bytes --]

#
# Author:  Russell Coker <russell@coker.com.au>
#

#################################
#
# Rules for the squid_t domain.
#
# squid_t is the domain the squid process runs in, and is also the SID for
# files in /usr/lib/squid
type squid_t, domain, privlog;
# var_log_squid_t is for /var/log/squid
type var_log_squid_t, file_type, sysadmfile;
# main squid binary is of squid_exec_t
type squid_exec_t, file_type, sysadmfile, exec_type;

# Inherit and use descriptors from init.
allow squid_t init_t:fd inherit_fd_perms;

# Create pid file.
type squid_var_run_t, file_type, sysadmfile, pidfile;
file_type_auto_trans(squid_t, var_run_t, squid_var_run_t)

# httpd_cache_t is for /var/cache/squid
allow squid_t httpd_cache_t:dir create_dir_perms;
allow squid_t httpd_cache_t:file rw_file_perms;
file_type_auto_trans(squid_t, httpd_cache_t, httpd_cache_t)

allow squid_t var_log_squid_t:dir rw_dir_perms;
allow squid_t var_log_squid_t:file rw_file_perms;
file_type_auto_trans(squid_t, var_log_squid_t, var_log_squid_t)

# for /usr/lib/squid
allow squid_t squid_t:dir r_dir_perms;
allow squid_t squid_t:file r_file_perms;

can_network(squid_t)
# port 8080 is http_port
allow squid_t http_port_t:tcp_socket name_bind;
allow squid_t squid_t:file { execute_no_trans execute };
allow squid_t squid_exec_t:file execute_no_trans;

domain_auto_trans(initrc_t, squid_exec_t, squid_t)

[-- Attachment #3: squid --]
[-- Type: application/x-shellscript, Size: 2425 bytes --]

Re: Squid policy for SE Linux

[Stephen Smalley]

On Wed, 6 Mar 2002, Russell Coker wrote:

> I have attached my squid.te file.

Thanks.  I'm not familiar with squid, but I'll provide some comments on
the policy below.

> Here's the relevant parts of my file_contexts file:
> /var/cache/squid(|/.*)          system_u:object_r:httpd_cache_t

I'm unclear as to whether it is a good idea to use the same type here as
for /var/cache/httpd.  Do you really want to grant squid and httpd the
same set of accesses to both /var/cache/httpd and /var/cache/squid?

> /usr/lib/squid                  system_u:object_r:squid_t

In a TE policy, you typically keep the domain space and the object type
space separate - i.e. you never use a domain as a file type.  In SELinux,
there is a special case for the /proc/PID entries of a process, which are
labeled with the SID of the process (and hence its domain).  If you use
the domain for other files, the policy won't be able to distinguish
between the /proc/PID entries and these other files.  So I would recommend
using a different type here, possibly just leaving it in lib_t unless you
truly need to separate it.

> I also added squid_t to system_r in the rbac file.

I've partitioned the role declarations up among the various .te files in
our internal copy of the policy, so this will actually be moved into
squid.te.

My comments on your squid.te file are below:

># squid_t is the domain the squid process runs in, and is also the SID
>for
># files in /usr/lib/squid
>type squid_t, domain, privlog;

As I mentioned above, I wouldn't recommend using this domain as a file
type.  Also, since you didn't include the file_type attribute, the kernel
should have denied your attempt to relabel the file to this domain, unless
you were running in permissive mode at the time.  In contrast, the kernel
is free to apply the domain to pseudo files that it generates like
/proc/PID.

># httpd_cache_t is for /var/cache/squid
>allow squid_t httpd_cache_t:dir create_dir_perms;
>allow squid_t httpd_cache_t:file rw_file_perms;
>file_type_auto_trans(squid_t, httpd_cache_t, httpd_cache_t)

As I also mentioned above, I'm not sure if you want to use the same type
that is being used for /var/cache/httpd.  Make sure that there aren't any
implications of granting both squid and httpd the same set of permissions
to both sets of files.

>allow squid_t var_log_squid_t:dir rw_dir_perms;
>allow squid_t var_log_squid_t:file rw_file_perms;
>file_type_auto_trans(squid_t, var_log_squid_t, var_log_squid_t)

You only need a file_type_auto_trans rule if you want the new file to
inherit a type other than the type of the parent directory.  If
/var/log/squid were a file or directory that was created (or recreated) at
runtime by squid, then you would need a rule like
	file_type_auto_trans(squid_t, var_log_t, var_log_squid_t)
to ensure that it was created with the right type.  But if /var/log/squid
is always created during installation and you initially label it with
the type, then all files created within it will inherit that type
automatically without needing the file_type_auto_trans rule.

However, if you remove the file_type_auto_trans rule, you will need to
expand the allow statements to allow creation of files within the
directory, e.g.:
	allow squid_t var_log_squid_t:dir rw_dir_perms;
	allow squid_t var_log_squid_t:file create_file_perms;
You might need create_dir_perms in the first rule if squid needs to create
subdirectories within /var/log/squid.

># for /usr/lib/squid
>allow squid_t squid_t:dir r_dir_perms;
>allow squid_t squid_t:file r_file_perms;
>allow squid_t squid_t:file { execute_no_trans execute };

As mentioned above, I'd suggest using a different type for /usr/lib/squid,
possibly leaving it in lib_t.  For the execute-related permissions, I'd
suggest using can_exec(squid_t, lib_t) or whatever your type is.

>allow squid_t squid_exec_t:file execute_no_trans;

I'm not clear as to why this is needed, unless squid re-executes itself at
times.  The domain_auto_trans rule handles giving permissions to initially
enter the domain via this executable.  In any case, I'd suggest using the
can_exec macro, e.g.
	can_exec(squid_t, squid_exec_t)

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com









--
You have received this message because you are subscribed to the selinux 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: Squid policy for SE Linux

[Russell Coker]

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

On Wed, 6 Mar 2002 18:24, Stephen Smalley wrote:
> > Here's the relevant parts of my file_contexts file:
> > /var/cache/squid(|/.*)          system_u:object_r:httpd_cache_t
>
> I'm unclear as to whether it is a good idea to use the same type here as
> for /var/cache/httpd.  Do you really want to grant squid and httpd the
> same set of accesses to both /var/cache/httpd and /var/cache/squid?

Firstly I doubt that anyone would use both apache and Squid to act as web 
caches.  So it made sense to me at the time.

Now I think it should be squid_cache_t instead.

> > /usr/lib/squid                  system_u:object_r:squid_t
>
> In a TE policy, you typically keep the domain space and the object type
> space separate - i.e. you never use a domain as a file type.  In SELinux,
> there is a special case for the /proc/PID entries of a process, which are
> labeled with the SID of the process (and hence its domain).  If you use
> the domain for other files, the policy won't be able to distinguish
> between the /proc/PID entries and these other files.  So I would recommend
> using a different type here, possibly just leaving it in lib_t unless you
> truly need to separate it.

OK.  I'll change it to lib_t then.

> > I also added squid_t to system_r in the rbac file.
>
> I've partitioned the role declarations up among the various .te files in
> our internal copy of the policy, so this will actually be moved into
> squid.te.

Great!  It was becoming difficult to manage with everything in the rbac file.

> My comments on your squid.te file are below:
> ># squid_t is the domain the squid process runs in, and is also the SID
> >for
> ># files in /usr/lib/squid
> >type squid_t, domain, privlog;
>
> As I mentioned above, I wouldn't recommend using this domain as a file
> type.  Also, since you didn't include the file_type attribute, the kernel
> should have denied your attempt to relabel the file to this domain, unless
> you were running in permissive mode at the time.  In contrast, the kernel
> is free to apply the domain to pseudo files that it generates like
> /proc/PID.

I am running in permissive mode.  I haven't got enough policy written to be 
confident that my machine can keep operating in enforcing mode.  Also the 
problems previously discussed regarding devfs and tty permissions is a 
serious roadblock for me.

> ># httpd_cache_t is for /var/cache/squid
> >allow squid_t httpd_cache_t:dir create_dir_perms;
> >allow squid_t httpd_cache_t:file rw_file_perms;
> >file_type_auto_trans(squid_t, httpd_cache_t, httpd_cache_t)
>
> As I also mentioned above, I'm not sure if you want to use the same type
> that is being used for /var/cache/httpd.  Make sure that there aren't any
> implications of granting both squid and httpd the same set of permissions
> to both sets of files.

Yes, that is something I hadn't thought through.  While we only have one of 
these programs active on a typical system there is the potential that someone 
could use a squid bug to attach Apache (or the other way around).

> >allow squid_t var_log_squid_t:dir rw_dir_perms;
> >allow squid_t var_log_squid_t:file rw_file_perms;
> >file_type_auto_trans(squid_t, var_log_squid_t, var_log_squid_t)
>
> You only need a file_type_auto_trans rule if you want the new file to
> inherit a type other than the type of the parent directory.  If
> /var/log/squid were a file or directory that was created (or recreated) at
> runtime by squid, then you would need a rule like
> 	file_type_auto_trans(squid_t, var_log_t, var_log_squid_t)
> to ensure that it was created with the right type.  But if /var/log/squid
> is always created during installation and you initially label it with
> the type, then all files created within it will inherit that type
> automatically without needing the file_type_auto_trans rule.

That part is clear from the example policy you wrote.

However in this instance /var/log/squid is a directory containing files that 
are created by Squid.  So I think that my policy above is what is required 
(at least it seems to work OK).

> ># for /usr/lib/squid
> >allow squid_t squid_t:dir r_dir_perms;
> >allow squid_t squid_t:file r_file_perms;
> >allow squid_t squid_t:file { execute_no_trans execute };
>
> As mentioned above, I'd suggest using a different type for /usr/lib/squid,
> possibly leaving it in lib_t.  For the execute-related permissions, I'd
> suggest using can_exec(squid_t, lib_t) or whatever your type is.

OK.

> >allow squid_t squid_exec_t:file execute_no_trans;
>
> I'm not clear as to why this is needed, unless squid re-executes itself at
> times.

It appears to do that.  I'm not sure why, maybe Mike can shed some light.

> The domain_auto_trans rule handles giving permissions to initially
> enter the domain via this executable.  In any case, I'd suggest using the
> can_exec macro, e.g.
> 	can_exec(squid_t, squid_exec_t)

OK.

I've attached my latest squid.te file with changes as per your suggestions.

Also I think that we should review the port types, I think that having a 
sample policy of ports 8080 and 80 having the same type is a bad idea.  80 is 
the standard web serving port (with some minor use by web caches), 8080 is 
the non-standard but most common port for web caches (but almost never web 
serving).  It would make sense to have a different port type for 8080, allow 
both Apache and Squid to use 8080, but allow Squid only 8080 and other cache 
ports.

Squid also commonly uses TCP port 3128 (instead of 8080), and UDP port 3130.  
Squid is written to support TCP port 4827 for cache digests and it would 
probably be best if this is included in sample policy even though most people 
don't use it.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

[-- Attachment #2: squid.te --]
[-- Type: text/plain, Size: 1524 bytes --]

#
# Author:  Russell Coker <russell@coker.com.au>
#

#################################
#
# Rules for the squid_t domain.
#
# squid_t is the domain the squid process runs in
type squid_t, domain, privlog;

# var_log_squid_t is for /var/log/squid
type var_log_squid_t, file_type, sysadmfile;

# main squid binary is of squid_exec_t
type squid_exec_t, file_type, sysadmfile, exec_type;

# type for /var/cache/squid
type squid_cache_t, file_type, sysadmfile;

# Inherit and use descriptors from init.
allow squid_t init_t:fd inherit_fd_perms;

# Create pid file.
type squid_var_run_t, file_type, sysadmfile, pidfile;
file_type_auto_trans(squid_t, var_run_t, squid_var_run_t)

# squid_cache_t is for /var/cache/squid
allow squid_t squid_cache_t:dir create_dir_perms;
allow squid_t squid_cache_t:file rw_file_perms;
file_type_auto_trans(squid_t, squid_cache_t, squid_cache_t)

allow squid_t var_log_squid_t:dir rw_dir_perms;
allow squid_t var_log_squid_t:file rw_file_perms;
file_type_auto_trans(squid_t, var_log_squid_t, var_log_squid_t)

# for /usr/lib/squid
allow squid_t squid_t:dir r_dir_perms;
allow squid_t squid_t:file r_file_perms;

can_network(squid_t)
# port 8080 is http_port
allow squid_t http_port_t:tcp_socket name_bind;
allow squid_t squid_t:file { execute_no_trans execute };
allow squid_t squid_exec_t:file execute_no_trans;

domain_auto_trans(initrc_t, squid_exec_t, squid_t)

# to allow running programs from /usr/lib/squid (IE unlinkd)
# also allow exec()ing itself
can_exec(squid_t, { lib_t squid_exec_t } )

Re: Squid policy for SE Linux

[Dale Amon]

On Wed, Mar 06, 2002 at 09:00:22PM +0100, Russell Coker wrote:

> > >allow squid_t squid_exec_t:file execute_no_trans;
> >
> > I'm not clear as to why this is needed, unless squid re-executes itself at
> > times.
> 
> It appears to do that.  I'm not sure why, maybe Mike can shed some light.

I know squid has multiple instances of itself, and
you often have perl scripts attached as filters. I've
often used this for systems that need to capture the
first web access attempt and replace it with a portal
page. 

I think those instances are started as required, but
it's been about 2 years since I worked on this.

-- 
------------------------------------------------------
    Nuke bin Laden:           Dale Amon, CEO/MD
  improve the global          Islandone Society
     gene pool.               www.islandone.org
------------------------------------------------------

--
You have received this message because you are subscribed to the selinux 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.