From: domg472@gmail.com (Dominick Grift)
Date: Sun, 19 Jul 2009 11:37:48 +0200
Subject: [refpolicy] Critique requested
In-Reply-To: <20090718230224.GB26512@deer-run.com>
References: <20090718230224.GB26512@deer-run.com>
Message-ID: <1247996268.2564.38.camel@notebook1.grift.internal>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Sat, 2009-07-18 at 16:02 -0700, Hal Pomeranz wrote:
> I'm still wrapping my head around the SELinux Reference Policy, but
> I was curious if the experts on this list would like to comment on
> the sample policy files below.  It's a simple policy for the old
> portsentry HIDS.  It's not a complete policy by any means, since I've
> just been testing in "stealth mode" and not triggering any actions
> on detects, but it's a start.  I'm curious if I'm making any stylistic
> or technical errors.

Alright, as for your portsentry.fc.

Your entries should go in alphabetical order.

Some tips with regards to file context regular expressions:

Try to make your entries as fine grained as possible.

As for your portsentry.te.

The policy_module() declaration should be on the second line (first line
in the portsentry.te file should be blank(empty)

The portsentry private declaration and policy headers layout should look
something like this:

########################################
#
# Portsentry private declarations
#

########################################
#
# Portsentry private policy
#

The following block of declaration has duplicates:

type portsentry_t;
domain_type(portsentry_t)
role system_r types portsentry_t;

type portsentry_exec_t;
domain_entry_file(portsentry_t, portsentry_exec_t)
init_daemon_domain(portsentry_t, portsentry_exec_t)

This can be minimized to this (see the init_daemon_domain() interface in
init.if why):

type portsentry_t;
type portsentry_exec_t;
init_daemon_domain(portsentry_t, portsentry_exec_t)

Next is:

# limited since we're going to allow binding to everything
define(`portsentry_socket_perms', `{ bind connect create listen read
write }')

Permission sets are not defined in a policy module. Also you do not have
to define one yourself. You could just use create_socket_permms instead.

allow portsentry_t self:tcp_socket portsentry_socket_perms;
allow portsentry_t self:udp_socket portsentry_socket_perms;
allow portsentry_t self:unix_dgram_socket portsentry_socket_perms;
allow portsentry_t self:rawip_socket portsentry_socket_perms;
allow portsentry_t self:capability { net_raw net_bind_service };
allow portsentry_t self:process fork;

This block of policy should be the first policy in your "Portsentry
private policy" section. This block should be in alphabetical order.

also the portsentry_socket_perms should be replaced by
create_socket_perms.

allow portsentry_t portsentry_etc_t:dir list_dir_perms;
allow portsentry_t portsentry_etc_t:file read_file_perms;
allow portsentry_t portsentry_log_t:dir list_dir_perms;
allow portsentry_t portsentry_log_t:file rw_file_perms;

These look fine but: see if the rw_file_perms for portsentry_log_t can
be narrowed to append.

create_files_pattern(portsentry, portsentry_log_t, portsentry_log_t)
append_files_pattern(portsentry, portsentry_log_t. portsentry_log_t)
logging_log_filetrans(portsentry, portsentry_log_t, { dir file })

Assuming portsentry needs to be able to create its log file and/ or
dirs.

The reason we replaced the rw_file_perms by create and append is because
we do not want to have portsentry write to its log file ( A compromized
portsentry_t domain might try to wipe its trail in log file)

This ofcourse is assuming that portsentry itself opens the log file for
append. (see if that is so)

corenet_tcp_bind_all_ports(portsentry_t)
corenet_tcp_bind_all_nodes(portsentry_t)
corenet_udp_bind_all_ports(portsentry_t)
corenet_udp_bind_all_nodes(portsentry_t)
kernel_sendrecv_unlabeled_packets(portsentry_t)

First and foremost it is not encouraged to allow your domain to bind tcp
and udp sockets to all ports. You should, if possible, declare a
portsentry port type and allow portsentry to only bind sockets to those.

remove the kernel_sendrecv_unlabeled_packets(portsentry_t)

Also to support backwards compatibility and features you should extend
the network policy section to read:

corenet_all_recvfrom_unlabeled(portsentry_t)
corenet_all_recvfrom_netlabel(portsentry_t)
corenet_tcp_sendrecv_generic_if(portsentry_t)
corenet_udp_sendrecv_generic_if(porsentry_t)
corenet_tcp_sendrecv_generic_node(portsentry_t)
corenet_udp_sendrecv_generic_node(portsentry_t)
corenet_tcp_sendrecv_all_ports(portsentry_t)
corenet_udp_sendrecv_all_ports(portsentry_t)
corenet_tcp_bind_generic_node(portsentry_t)

And if you have declared your portsentry ports properly you would add:

corenet_tcp_bind_portsentry_port(portsentry_t)
corenet_udp_bind_portsentry_port(portsentry_t)

The rest of your policy should be in alphabetical order:

this:

logging_send_syslog_msg(portsentry_t)
miscfiles_read_localization(portsentry_t)
files_search_etc(portsentry_t)
files_search_var_lib(portsentry_t)

should look like:

files_search_etc(portsentry_t)
files_search_var_lib(portsentry_t)

logging_send_syslog_msg(portsentry_t)

miscfiles_read_localization(portsentry_t)


If you want to write policy acceptable bu upstream than take their
reference policy as an example. It is browse-able online. Have a look at
some of the excellent examples included like for example apache policy.

Compare different examples in there and youll notice the properties that
all policies have in common (with the occasional exception)

http://oss.tresys.com/projects/refpolicy/browser/

Disclaimer: i might have made errors.

Hope this helps.


> Also a question, if I may.  I originally compiled portsentry from
> source as a standard dynamically-linked executable.  However, when I
> started this binary under SELinux control I kept getting denials on
> the shared library "lib_t" files and directories as well as on various
> "ld_so*_t" files.  Recompiling as a statically-linked executable made
> this problem go away (obviously), but what's the magic to get a
> standard dynamically-linked executable to not generate these errors?
> I've looked at the sample files in the refpolicy source and haven't
> been able to figure out the trick.
> 
> FWIW I've been doing my testing on a CentOS (RHEL) 5.3 system.  It
> doesn't have the latest and greatest version of refpolicy installed by
> default, but it's a fairly recent version.
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy