[refpolicy] Critique requested

[refpolicy] Critique requested

[Hal Pomeranz]

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.

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.

-- 
Hal Pomeranz, Founder/CEO      Deer Run Associates      hal at deer-run.com
    Network Connectivity and Security, Systems Management, Training
-------------- next part --------------
/usr/local/sbin/portsentry	--	gen_context(system_u:object_r:portsentry_exec_t,s0)
/etc/portsentry(/.*)?			gen_context(system_u:object_r:portsentry_etc_t,s0)
/var/lib/portsentry(/.*)?		gen_context(system_u:object_r:portsentry_log_t,s0)
-------------- next part --------------
policy_module(portsentry, 1.0.4)

#### Declarations

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)

type portsentry_etc_t;
files_config_file(portsentry_etc_t)

type portsentry_log_t;
logging_log_file(portsentry_log_t);

#### Policy

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

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;

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;

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)

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

[refpolicy] Critique requested

[Dominick Grift]

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

[refpolicy] Critique requested

[Hal Pomeranz]

Thanks to Dominick for critiquing my initial attempts at using 
the Reference Policy.  I'm still curious about the answer to the
following question, if anybody on the list has some insights:

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

-- 
Hal Pomeranz, Founder/CEO      Deer Run Associates      hal at deer-run.com
    Network Connectivity and Security, Systems Management, Training

[refpolicy] Critique requested

[Chris PeBenito]

On Mon, 2009-07-27 at 09:13 -0700, Hal Pomeranz wrote:
> Thanks to Dominick for critiquing my initial attempts at using 
> the Reference Policy.  I'm still curious about the answer to the
> following question, if anybody on the list has some insights:
> 
> > > 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.

All types that are a domain should have this access.

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

[refpolicy] Critique requested

[Martin Orr]

On 27/07/09 17:13, Hal Pomeranz wrote:
> Thanks to Dominick for critiquing my initial attempts at using 
> the Reference Policy.  I'm still curious about the answer to the
> following question, if anybody on the list has some insights:
> 
>>> 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.


This permission is given by:
	libs_use_ld_so(domain)
	libs_use_shared_libs(domain)
in kernel/domain.te.

Any type declared with domain_type will get these permissions.

If you still see denials for these after using domain_type, then maybe you
are using an old policy: this was added to the policy in October 2008.

-- 
Martin Orr