ntp policy

ntp policy

[Christopher J. PeBenito]

While converting the ntpd policy over to a reference policy module, I
came across a few lines which bring up questions.

	# so the start script can change firewall entries
	allow initrc_t net_conf_t:file { getattr read ioctl };

This looks like a distro-specific access, or perhaps it just made its
way in by accident?

	# for cron jobs
	# system_crond_t is not right, cron is not doing what it should
	ifdef(`crond.te', `
	system_crond_entry(ntpd_exec_t, ntpd_t)
	')

It is unclear to me what the comment means.  Also, shouldn't this be
ntpdate_exec_t instead of ntpd_exec_t?

	can_udp_send(ntpd_t, sysadm_t)
	can_udp_send(sysadm_t, ntpd_t)

There is no comment for these.  Are they needed for sysadm to run
ntpdate?

	ifdef(`winbind.te', `
	allow ntpd_t winbind_var_run_t:dir r_dir_perms;
	allow ntpd_t winbind_var_run_t:sock_file rw_file_perms;
	')

Generally when using a sock_file, a domain is connecting/sending to
another domain over a unix domain socket; however, after doing a few
rule searches in apol, I find no evidence that ntpd_t connects/sends to
winbind_t.  Is there some other purpose for these rules, or am I missing
something?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: ntp policy

[Daniel J Walsh]

Christopher J. PeBenito wrote:

>While converting the ntpd policy over to a reference policy module, I
>came across a few lines which bring up questions.
>
>	# so the start script can change firewall entries
>	allow initrc_t net_conf_t:file { getattr read ioctl };
>
>This looks like a distro-specific access, or perhaps it just made its
>way in by accident?
>  
>
No idea.  You get these from the can_network call anyways.

>	# for cron jobs
>	# system_crond_t is not right, cron is not doing what it should
>	ifdef(`crond.te', `
>	system_crond_entry(ntpd_exec_t, ntpd_t)
>	')
>
>It is unclear to me what the comment means.  Also, shouldn't this be
>ntpdate_exec_t instead of ntpd_exec_t?
>  
>
Yes, I am sure this rule went in before there was an ntpdate_exec_t, 
although I do not see a cron job that runs it.

>	can_udp_send(ntpd_t, sysadm_t)
>	can_udp_send(sysadm_t, ntpd_t)
>
>There is no comment for these.  Are they needed for sysadm to run
>ntpdate?
>  
>
>	ifdef(`winbind.te', `
>	allow ntpd_t winbind_var_run_t:dir r_dir_perms;
>	allow ntpd_t winbind_var_run_t:sock_file rw_file_perms;
>	')
>
>Generally when using a sock_file, a domain is connecting/sending to
>another domain over a unix domain socket; however, after doing a few
>rule searches in apol, I find no evidence that ntpd_t connects/sends to
>winbind_t.  Is there some other purpose for these rules, or am I missing
>something?
>
>  
>
Must be from nscd.


-- 



--
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: ntp policy

[Christopher J. PeBenito]

On Wed, 2005-09-07 at 08:16 -0400, Daniel J Walsh wrote:
> Christopher J. PeBenito wrote:
> 
> >While converting the ntpd policy over to a reference policy module, I
> >came across a few lines which bring up questions.
[cut]
> >	ifdef(`winbind.te', `
> >	allow ntpd_t winbind_var_run_t:dir r_dir_perms;
> >	allow ntpd_t winbind_var_run_t:sock_file rw_file_perms;
> >	')
> >
> >Generally when using a sock_file, a domain is connecting/sending to
> >another domain over a unix domain socket; however, after doing a few
> >rule searches in apol, I find no evidence that ntpd_t connects/sends to
> >winbind_t.  Is there some other purpose for these rules, or am I missing
> >something?
> >
> Must be from nscd.

I don't understand.  If that is the case, wouldn't it be nscd_var_run_t
instead of winbind_var_run_t?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: ntp policy

[Daniel J Walsh]

Christopher J. PeBenito wrote:

>On Wed, 2005-09-07 at 08:16 -0400, Daniel J Walsh wrote:
>  
>
>>Christopher J. PeBenito wrote:
>>
>>    
>>
>>>While converting the ntpd policy over to a reference policy module, I
>>>came across a few lines which bring up questions.
>>>      
>>>
>[cut]
>  
>
>>>	ifdef(`winbind.te', `
>>>	allow ntpd_t winbind_var_run_t:dir r_dir_perms;
>>>	allow ntpd_t winbind_var_run_t:sock_file rw_file_perms;
>>>	')
>>>
>>>Generally when using a sock_file, a domain is connecting/sending to
>>>another domain over a unix domain socket; however, after doing a few
>>>rule searches in apol, I find no evidence that ntpd_t connects/sends to
>>>winbind_t.  Is there some other purpose for these rules, or am I missing
>>>something?
>>>
>>>      
>>>
>>Must be from nscd.
>>    
>>
>
>I don't understand.  If that is the case, wouldn't it be nscd_var_run_t
>instead of winbind_var_run_t?
>
>  
>
I believe that in permissive mode, you would eventually get to the point 
of talking over the winbind socket.  So these rules were porbably added 
for this purpose.  Since ntpd is in nscd_client_domain, these rules are 
probably not necessary.

-- 



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

ntp policy

[Russell Coker]

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

Here's my latest effort at a ntpd policy, first the file_contexts entries:
/var/lib/ntp(|/.*)              system_u:object_r:var_lib_ntp_t
/etc/ntp.conf                   system_u:object_r:etc_ntp_t
/usr/sbin/ntpd                  system_u:object_r:ntpd_exec_t
/var/log/ntpstats(|/.*)         system_u:object_r:var_log_ntp_t
/var/log/ntpd                   system_u:object_r:var_log_ntp_t

I've attached the ntp.te file.

Note that I'm using my version of uses_shlib that is as follows:
define(`uses_shlib',`
allow $1 ld_so_t:file rx_file_perms;
allow $1 ld_so_t:file execute_no_trans;
allow $1 ld_so_t:lnk_file r_file_perms;
allow $1 shlib_t:file rx_file_perms;
allow $1 shlib_t:lnk_file r_file_perms;
allow $1 ld_so_cache_t:file r_file_perms;
allow $1 lib_t:dir r_dir_perms;
')

-- 
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: ntp.te --]
[-- Type: text/plain, Size: 1441 bytes --]

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

#################################
#
# Rules for the ntpd_t domain.
#
type ntpd_t, domain, privlog;
type ntpd_exec_t, file_type, sysadmfile, exec_type;
type var_lib_ntp_t, file_type, sysadmfile;
type var_log_ntp_t, file_type, sysadmfile;
type etc_ntp_t, file_type, sysadmfile;

role system_r types ntpd_t;

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

allow ntpd_t init_t:process sigchld;

uses_shlib(ntpd_t)
allow ntpd_t root_t:dir r_dir_perms;

# Create pid file.
type var_run_ntp_t, file_type, sysadmfile, pidfile;
file_type_auto_trans(ntpd_t, var_run_t, var_run_ntp_t)
file_type_auto_trans(ntpd_t, var_log_t, var_log_ntp_t)

allow ntpd_t { var_lib_t usr_t }:dir r_dir_perms;
allow ntpd_t usr_t:file r_file_perms;
allow ntpd_t null_device_t:chr_file rw_file_perms;
allow ntpd_t { var_lib_ntp_t var_log_ntp_t }:dir rw_dir_perms;
allow ntpd_t { var_lib_ntp_t var_log_ntp_t }:file rw_file_perms;

allow ntpd_t self:capability { sys_time net_bind_service ipc_lock };

allow ntpd_t etc_t:dir r_dir_perms;
allow ntpd_t etc_t:lnk_file r_file_perms;
allow ntpd_t etc_ntp_t:file rw_file_perms;

# Use the network.
can_network(ntpd_t)
allow ntpd_t domain:packet_socket recvfrom;
allow ntpd_t self:unix_dgram_socket create_socket_perms;

allow ntpd_t self:process fork;

domain_auto_trans(initrc_t, ntpd_exec_t, ntpd_t)

allow ntpd_t fs_t:filesystem getattr;

Re: ntp policy

[Stephen Smalley]

On Wed, 20 Mar 2002, Russell Coker wrote:

> I've attached the ntp.te file.

Thanks.  A few comments and questions below.

>allow ntpd_t root_t:dir r_dir_perms;

This rule can probably be generalized and moved into uses_shlib as well,
as you've done with the lib_t permissions.  Probably usr_t as well
to pick up /usr/lib.

>allow ntpd_t { var_lib_ntp_t var_log_ntp_t }:dir rw_dir_perms;
>allow ntpd_t { var_lib_ntp_t var_log_ntp_t }:file rw_file_perms;

These rules should be handled already by the file_type_auto_trans
macros, which both set up the type transition rule and grant the
necessary permissions to create and access files of these types.

>allow ntpd_t domain:packet_socket recvfrom;

Does ntpd truly need the ability to receive from any domain?

>allow ntpd_t self:unix_dgram_socket create_socket_perms;

What domains need to be able to send to this socket?

>allow ntpd_t self:process fork;

Might ntpd need the ability to signal forked copies of itself?

--
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: ntp policy

[Stephen Smalley]

On Wed, 20 Mar 2002, Stephen Smalley wrote:

> >allow ntpd_t { var_lib_ntp_t var_log_ntp_t }:dir rw_dir_perms;
> >allow ntpd_t { var_lib_ntp_t var_log_ntp_t }:file rw_file_perms;
>
> These rules should be handled already by the file_type_auto_trans
> macros, which both set up the type transition rule and grant the
> necessary permissions to create and access files of these types.

Sorry, the above comment only applies to var_log_ntp_t, since there is no
file_type_auto_trans rule for var_lib_ntp_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: ntp policy

[Russell Coker]

On Wed, 20 Mar 2002 22:01, Stephen Smalley wrote:
> On Wed, 20 Mar 2002, Russell Coker wrote:
> > I've attached the ntp.te file.
>
> Thanks.  A few comments and questions below.
>
> >allow ntpd_t root_t:dir r_dir_perms;
>
> This rule can probably be generalized and moved into uses_shlib as well,
> as you've done with the lib_t permissions.  Probably usr_t as well
> to pick up /usr/lib.

What about the following:
#################################
#
# uses_shlib(domain)
#
# Permissions for using shared libraries.
#
define(`uses_shlib',`
allow $1 { root_t usr_t var_t }:dir r_dir_perms;
allow $1 ld_so_t:file rx_file_perms;
allow $1 ld_so_t:file execute_no_trans;
allow $1 ld_so_t:lnk_file r_file_perms;
allow $1 shlib_t:file rx_file_perms;
allow $1 shlib_t:lnk_file r_file_perms;
allow $1 ld_so_cache_t:file r_file_perms;
allow $1 lib_t:dir r_dir_perms;
allow $1 lib_t:file rx_file_perms;
')

#################################
#
# uses_base_bins(domain)
#
# Permissions for running basic programs
#
define(`uses_base_bins',`
uses_shlib($1)
allow $1 bin_t:dir r_dir_perms;
allow $1 bin_t:{ file lnk_file } r_file_perms;
')dnl

Then we can have some other macros which use uses_base_bins (which probably 
isn't a good name) and add extra functionality of executing shells or sbin_t.

How about the following for defining domains for daemons:
define(`daemon_domain', `
type $1_t, domain, privlog;
type $1_exec_t, file_type, sysadmfile, exec_type;

role system_r types $1_t;

domain_auto_trans(initrc_t, $1_exec_t, $1_t)

# Inherit and use descriptors from init.
allow $1_t { init_t newrole_t }:fd inherit_fd_perms;
allow $1_t { init_t newrole_t }:process sigchld;
allow $1_t self:process signal;

uses_shlib($1_t)

# Create pid file.
type var_run_$1_t, file_type, sysadmfile, pidfile;
file_type_auto_trans($1_t, var_run_t, var_run_$1_t)

allow $1_t self:process fork;
')dnl

> >allow ntpd_t domain:packet_socket recvfrom;
>
> Does ntpd truly need the ability to receive from any domain?

Not certain, I'll have to look into it again.

> >allow ntpd_t self:unix_dgram_socket create_socket_perms;
>
> What domains need to be able to send to this socket?

Only itself apparently, here's the log:
Mar 20 22:57:53 lyta kernel: avc:  denied  { create } for  pid=18529 
exe=/usr/sbin/ntpd scontext=system_u:system_r:ntpd_t 
tcontext=system_u:system_r:ntpd_t tclass=unix_dgram_socket
Mar 20 22:57:53 lyta kernel: avc:  denied  { connect } for  pid=18529 
exe=/usr/sbin/ntpd scontext=system_u:system_r:ntpd_t 
tcontext=system_u:system_r:ntpd_t tclass=unix_dgram_socket
Mar 20 22:57:53 lyta kernel: avc:  denied  { write } for  pid=18529 
exe=/usr/sbin/ntpd scontext=system_u:system_r:ntpd_t 
tcontext=system_u:system_r:ntpd_t tclass=unix_dgram_socket

> >allow ntpd_t self:process fork;
>
> Might ntpd need the ability to signal forked copies of itself?

Good point, I guess so.

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

--
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: ntp policy

[Stephen Smalley]

On Wed, 20 Mar 2002, Russell Coker wrote:

> #################################
> #
> # uses_shlib(domain)
> #
> # Permissions for using shared libraries.
> #
> define(`uses_shlib',`
> allow $1 { root_t usr_t var_t }:dir r_dir_perms;

Why var_t?  If you want /var/lib, then you'll need var_lib_t as well, but
it isn't clear to me that you need it.  Also, you can put lib_t here
rather than separately below.

> allow $1 ld_so_t:file rx_file_perms;
> allow $1 ld_so_t:file execute_no_trans;
> allow $1 ld_so_t:lnk_file r_file_perms;
> allow $1 shlib_t:file rx_file_perms;
> allow $1 shlib_t:lnk_file r_file_perms;
> allow $1 ld_so_cache_t:file r_file_perms;
> allow $1 lib_t:dir r_dir_perms;
> allow $1 lib_t:file rx_file_perms;

I don't think you want the last rule in uses_shlib.  If the library is a
shared library, it should be labeled with shlib_t, so why grant execute
access to lib_t here?

> #################################
> #
> # uses_base_bins(domain)
> #
> # Permissions for running basic programs
> #
> define(`uses_base_bins',`
> uses_shlib($1)
> allow $1 bin_t:dir r_dir_perms;
> allow $1 bin_t:{ file lnk_file } r_file_perms;
> ')dnl
>
> Then we can have some other macros which use uses_base_bins (which probably
> isn't a good name) and add extra functionality of executing shells or sbin_t.

Do you want a separate macro like this, or do you want to add rules to the
can_exec and can_exec_any macros to make them more standalone?

> How about the following for defining domains for daemons:
> define(`daemon_domain', `
> type $1_t, domain, privlog;
> type $1_exec_t, file_type, sysadmfile, exec_type;
>
> role system_r types $1_t;
>
> domain_auto_trans(initrc_t, $1_exec_t, $1_t)
>
> # Inherit and use descriptors from init.
> allow $1_t { init_t newrole_t }:fd inherit_fd_perms;
> allow $1_t { init_t newrole_t }:process sigchld;

Why the newrole_t permissions?

> allow $1_t self:process signal;

You might want to use signal_perms here to pick up all of the signal
permissions.

> # Create pid file.
> type var_run_$1_t, file_type, sysadmfile, pidfile;
> file_type_auto_trans($1_t, var_run_t, var_run_$1_t)

Other possible candidates for file_type_auto_trans rules include
temporary files, log files, tmpfs/shm pseudo files, and lock files.

> allow $1_t self:process fork;

You'll also want sigchld if you allow forking, which will be handled
if you use signal_perms above.

On a different note, I'm wondering if we need a better mechanism for
coordinating your contributions to the example policy.  There is the CVS
tree at the sourceforge selinux site.  To date, we've been keeping a
pristine copy of each NSA public release imported on the vendor
branch under the 'nsa' directory.

--
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: ntp policy

[Russell Coker]

On Thu, 21 Mar 2002 20:15, Stephen Smalley wrote:
> > #################################
> > #
> > # uses_shlib(domain)
> > #
> > # Permissions for using shared libraries.
> > #
> > define(`uses_shlib',`
> > allow $1 { root_t usr_t var_t }:dir r_dir_perms;
>
> Why var_t?  If you want /var/lib, then you'll need var_lib_t as well, but
> it isn't clear to me that you need it.  Also, you can put lib_t here
> rather than separately below.

I think that I originally put it there as a sort of catch-all rule, misusing 
that macro a bit.  I've removed it now.

> > allow $1 ld_so_t:file rx_file_perms;
> > allow $1 ld_so_t:file execute_no_trans;
> > allow $1 ld_so_t:lnk_file r_file_perms;
> > allow $1 shlib_t:file rx_file_perms;
> > allow $1 shlib_t:lnk_file r_file_perms;
> > allow $1 ld_so_cache_t:file r_file_perms;
> > allow $1 lib_t:dir r_dir_perms;
> > allow $1 lib_t:file rx_file_perms;
>
> I don't think you want the last rule in uses_shlib.  If the library is a
> shared library, it should be labeled with shlib_t, so why grant execute
> access to lib_t here?

OK, so we have the following now:
define(`uses_shlib',`
allow $1 { root_t usr_t lib_t }:dir r_dir_perms;
allow $1 { ld_so_t shlib_t }:file rx_file_perms;
allow $1 ld_so_t:file execute_no_trans;
allow $1 shlib_t:lnk_file r_file_perms;
allow $1 ld_so_t:lnk_file r_file_perms;
allow $1 ld_so_cache_t:file r_file_perms;
allow $1 lib_t:file r_file_perms;
')

> > #################################
> > #
> > # uses_base_bins(domain)
> > #
> > # Permissions for running basic programs
> > #
> > define(`uses_base_bins',`
> > uses_shlib($1)
> > allow $1 bin_t:dir r_dir_perms;
> > allow $1 bin_t:{ file lnk_file } r_file_perms;
> > ')dnl
> >
> > Then we can have some other macros which use uses_base_bins (which
> > probably isn't a good name) and add extra functionality of executing
> > shells or sbin_t.
>
> Do you want a separate macro like this, or do you want to add rules to the
> can_exec and can_exec_any macros to make them more standalone?

can_exec() is great the way it is!  can_exec_any() should call uses_shlib() - 
you can't really execute many things without shlibs!  My suggestion for 
uses_base_bins() is essentially can_exec_any(), I must have overlooked it in 
the macros file.

> > How about the following for defining domains for daemons:
> > define(`daemon_domain', `
> > type $1_t, domain, privlog;
> > type $1_exec_t, file_type, sysadmfile, exec_type;
> >
> > role system_r types $1_t;
> >
> > domain_auto_trans(initrc_t, $1_exec_t, $1_t)
> >
> > # Inherit and use descriptors from init.
> > allow $1_t { init_t newrole_t }:fd inherit_fd_perms;
> > allow $1_t { init_t newrole_t }:process sigchld;
>
> Why the newrole_t permissions?

Because they seem to be needed for the tty devices.  But that might be 
related to my issues with using devfs instead of devpts.  I'll have to 
compile a new kernel with devpts and try it again.

> > allow $1_t self:process signal;
>
> You might want to use signal_perms here to pick up all of the signal
> permissions.

OK.

> > # Create pid file.
> > type var_run_$1_t, file_type, sysadmfile, pidfile;
> > file_type_auto_trans($1_t, var_run_t, var_run_$1_t)
>
> Other possible candidates for file_type_auto_trans rules include
> temporary files, log files, tmpfs/shm pseudo files, and lock files.

Yes.  I think that it's probably best to have other macros that do them in 
addition to the base stuff.

> > allow $1_t self:process fork;
>
> You'll also want sigchld if you allow forking, which will be handled
> if you use signal_perms above.

Yes, although the main need for a fork in the daemon is as part of the 
detaching process, it forks and then the parent process exits leaving the 
child inherited by init.

> On a different note, I'm wondering if we need a better mechanism for
> coordinating your contributions to the example policy.  There is the CVS
> tree at the sourceforge selinux site.  To date, we've been keeping a
> pristine copy of each NSA public release imported on the vendor
> branch under the 'nsa' directory.

I don't think it makes sense for me to do CVS commits at the moment while you 
are pointing out mistakes in every policy file I post.  But if you would 
commit the versions that meet your approval without waiting for a new main 
release it would be a definite advantage.  Then I can start using new macros 
without waiting for a new release.

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

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