From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 01 Nov 2010 11:28:30 -0400
Subject: [refpolicy] Adding support for the vlock program
In-Reply-To: <SNT139-w28A8B461992B78025D8A9EAB460@phx.gbl>
References: <SNT139-W13A043DA44CA6C4BB2E4A8AB420@phx.gbl>,
	<20101026112141.GC25458@localhost.localdomain>,
	<SNT139-w506345F22822AD286268D1AB440@phx.gbl>,
	<20101028085440.GA3874@localhost.localdomain>
	<SNT139-w28A8B461992B78025D8A9EAB460@phx.gbl>
Message-ID: <4CCEDC9E.3000500@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 10/30/10 07:38, TaurusHarry wrote:
> Hi Dom and Christ,
> 
> The attached is the v3 vlock.pp compliant with refpolicy coding style,
> tests passed.
> 
> Is it good enough for upstream? :-)

Merged.  I renamed the interfaces, and did a little reordering in the TE
file.  Is there any reason not to allow other admins (secadm, auditadm,
etc.) to run vlock?


> Date: Thu, 28 Oct 2010 10:54:42 +0200
> From: domg472 at gmail.com
> To: refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Adding support for the vlock program
> 
> On Thu, Oct 28, 2010 at 08:38:52AM +0000, TaurusHarry wrote:
>> 
>> Hi Dom,
>> 
>> Sorry I did have missed out your first email of your comments on the vlock.te file, I have improved and tested it, please find it in the attachment.
>> 
>> Also, please see my reply(prefixed by "[H]") to each of your comments embedded below, thanks!
>> 
>> Date: Tue, 26 Oct 2010 13:21:43 +0200
>> From: domg472 at gmail.com
>> To: refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Adding support for the vlock program
>> 
>> On Tue, Oct 26, 2010 a
>  t 09:40:52AM +0000, TaurusHarry wrote:
>> > 
>> > Hi refpolicy experts,
>> > 
>> > I have tried to developed a vlock.pp in order to run the vlock program(2.2.2 version) on top of the latest refpolicy git tree, please see the attachment.
>> > 
>> > I am testing on a qemu environment, the system administrator and unprivileged user could login from serial console or by ssh, both could use the vlock command to lock his current console successfully.
>> > 
>> > How could I contribute it back to the refpolicy git tree?
>> > 
>> > Any comment is greatly appreciated!
>> > 
>> > Best regards,
>> > Harry
>>  
>> Hi, i have some suggestions inline
>> >  		 	   		  
>>  
>> > From ad4692423bcb1e10d5b9f146eab86de09b37dbb3 Mon Sep 17 00:00:00 2001
>> > From: Harry Ciao <qingtao.cao@windriver.com>
>> > Date: Tue, 26 Oct 2010 14:34:11 +08
>  00
>> > Subject: [PATCH] Adding support for the vlock program
>> > 
>> > Adding support for the vlock program.
>> > 
>> > Tested on vlock-2.2.2, both system administrator and unprivileged user
>> > could make use of vlock to lock his console successfully.
>> > 
>> > Signed-off-by: Harry Ciao <harrytaurus2002@hotmail.com>
>> > ---
>> >  policy/modules/apps/vlock.fc        |    1 +
>> >  policy/modules/apps/vlock.if        |   48 ++++++++++++++++++++++++++
>> >  policy/modules/apps/vlock.te        |   63 +++++++++++++++++++++++++++++++++++
>> >  policy/modules/system/userdomain.if |    2 +
>> >  4 files changed, 114 insertions(+), 0 deletions(-)
>> >  create mode 100644 policy/modules/apps/vlock.fc
>> >  create mode 100644 policy/modules/apps/vlock.if
>> >  create mode 100644 policy/modules/apps/vlock.te
>> > 
>> > diff --
>  git a/policy/modules/apps/vlock.fc b/policy/modules/apps/vlock.fc
>> > new file mode 100644
>> > index 0000000..621d5fd
>> > --- /dev/null
>> > +++ b/policy/modules/apps/vlock.fc
>> > @@ -0,0 +1 @@
>> > +/usr/sbin/vlock-main	--	gen_context(system_u:object_r:vlock_exec_t,s0)
>> > diff --git a/policy/modules/apps/vlock.if b/policy/modules/apps/vlock.if
>> > new file mode 100644
>> > index 0000000..259575e
>> > --- /dev/null
>> > +++ b/policy/modules/apps/vlock.if
>> > @@ -0,0 +1,48 @@
>> > +## <summary>Policy for the vlock program.</summary>
>> > +
>> > +#######################################
>> > +## <summary>
>> > +## 	Execute vlock in the vlock domain.
>> > +## </summary>
>> > +## <param name="domain">
>> > +##	<summary>
>> > +##	Domain allowed access.
>> > +##	<
>  /summary>
>> > +## </param>
>> > +#
>> > +interface(`vlock_domtrans_vlock',`
>> > +	gen_require(`
>> > +		type vlock_t, vlock_exec_t;
>> > +	')
>> > +
>> > +	files_search_usr($1)
>>  
>> The files_search_usr is redundant since all domains are allowed to search it (have a look in domain.te where attribute domain is allowed to interact with libs andthese interfaces provides search access to usr_t 
>> 
>> [H]: Yes, you are absolutely right! I could get the slate of dir/file that the domain attribute is able to read or open by default by the sesearch tool.
>>  
>> > +	corecmd_search_bin($1)
>> > +	domtrans_pattern($1, vlock_exec_t, vlock_t)
>> > +')
>> > +
>> > +########################################
>> > +## <summary>
>> > +##	Execute vlock in the vlock domain, and
>> > +##	allow the specified role the vlock dom
>  ain,
>> > +##	and use the caller's terminal.
>> > +## </summary>
>> > +## <param name="domain">
>> > +##	<summary>
>> > +##	Domain allowed access.
>> > +##	</summary>
>> > +## </param>
>> > +## <param name="role">
>> > +##	<summary>
>> > +##	The role to be allowed the vlock domain.
>> > +##	</summary>
>> > +## </param>
>> > +## <rolecap/>
>> > +#
>> > +interface(`vlock_run_vlock',`
>> > +	gen_require(`
>> > +		type vlock_t;
>> > +	')
>> > +
>> > +	vlock_domtrans_vlock($1)
>> > +	role $2 types vlock_t;
>> > +')
>> > diff --git a/policy/modules/apps/vlock.te b/policy/modules/apps/vlock.te
>> > new file mode 100644
>> > index 0000000..f0fa315
>> > --- /dev/null
>> > +++ b/policy/modules/apps/vlock.te
>>
>   > @@ -0,0 +1,63 @@
>> > +policy_module(vlock, 1.0.0)
>> > +
>> > +########################################
>> > +#
>> > +# Declarations
>> > +#
>> > +
>> > +type vlock_t;
>> > +type vlock_exec_t;
>> > +application_domain(vlock_t,vlock_exec_t)
>> > +
>> > +
>> > +########################################
>> > +#
>> > +# Vlock local policy
>> > +#
>> > +
>> > +allow vlock_t self:fd use;
>> > +allow vlock_t self:fifo_file rw_fifo_file_perms;
>> > +allow vlock_t self:unix_dgram_socket { create connect };
>> > +allow vlock_t self:netlink_audit_socket { create_netlink_socket_perms nlmsg_relay };
>> > +
>> > +# dont audit the failed attempt of vlock_t to setuid/setgid, because
>> > +# 1. we used --enable_pam for vlock to use PAM to authenticate passwd
>> > +# 2. no guarantee that to 
>  make vlock setuid is safe
>> > +dontaudit vlock_t self:capability { setuid setgid };
>>  
>> With inter process communication (interaction with self) we have interaction with class process and capability on top of the stack (there are also somestyle rules for where to put dontaudit rules (see the refpolicy style guide)
>> 
>> [H]: Sorry I couldn't find the "refpolicy style guide", where could I get it? So far I guess I just bumped this dontaudit rule ahead of all those allow rules. 
>  
> Here it is: http://oss.tresys.com/projects/refpolicy/wiki/StyleGuide
>  
>> 
>> > +
>> > +kernel_read_system_state(vlock_t)
>> > +
>> > +corecmd_list_bin(vlock_t)
>> > +corecmd_read_bin_symlinks(vlock_t)
>> > +
>> > +files_read_etc_files(vlock_t)
>> > +files_read_var_files(vlock_t)
>> > +files_read_v
>  ar_symlinks(vlock_t)
>>  
>> Any idea what generic var content it needs to read and why it is labeled with the generic var_t type?
>> 
>> [H]: You are right, above two rules for var files/symlinks are not necessary. Moreover, even without calling the files_read_etc_files() the vlock_t has been granted the read permission on var_t files.
>> 
>> > +
>> > +init_rw_utmp(vlock_t)
>>  
>> We usually dont allow domain to write to utmp.
>> What we do it allow read access but dontaudit write access to utmp
>> 
>> [H]: It turns out that vlock_t doesn't have to read from or write into /var/run/utmp, so init_dontaudit_rw_utmp() is used.
>> 
>>  
>> > +
>> > +term_use_all_user_ttys(vlock_t)
>> > +term_use_all_user_ptys(vlock_t)
>> > +userdom_use_user_terminals(vlock_t)
>>  
>> > +
>> > +# Must call this interface otherwise PAM session will fail
>> > +# w
>  ith message of "terminal=? res=failed"
>> > +domain_use_interactive_fds(vlock_t)
>> > +
>> > +auth_domtrans_chk_passwd(vlock_t)
>> > +
>> > +miscfiles_read_localization(vlock_t)
>> > +
>> > +logging_send_syslog_msg(vlock_t)
>> > +
>> > +selinux_getattr_fs(vlock_t)
>>  
>> i think refpolicy usually dontaudits access to get attributes of /selinux.
>> i personally allow it because i like to keep dontaudits to a minimum and i dont see the big problem here but if you want this upstream then i think it probably should be dontaudited
>> 
>> [H]: vlock could run successfully despite unable to getattr of /selinux, so selinux_dontaudit_getattr_fs() is used.
>>  
>> > +
>> > +# When MLS enabled and vlock PAM config file using pam_tally2 module,
>> > +# if the caller's security level is > s0, the vlock domain should be able
>> > +# to write into /var/lo
>  g/tallylog file which is s0.
>> > +mls_file_write_all_levels(vlock_t)
>>  
>> Not sure here but it looks a bit coarse. is there no write down only instead of all levels?
>> 
>> [H]: Sorry not following your question here. but this interface is called only when "enable-mls" is enabled. Ideally, vlock_t should bypass MLS constraints only for the /var/log/tallylog file, if the pam_tally2 module is ever used by /etc/pam.d/vlock.
>  
> nevermind i will leave any comments about this issue to more authorative people. 
>  
>>  
>> > +
>> > +# vlock could be used successfully without the search permissions on
>> > +# home_root_t or user_home_dir_t, suppress the related error messages.
>> > +files_dontaudit_search_home(vlock_t)
>> > +userdom_dontaudit_search_user_home_dirs(vlock_t)
>>  
>> I think the second rule is probably redundant because if it cannot search /home it can never get to /home/.* and 
>  so there should be no need to dontaudit it in my view.
>> 
>> [H]: Well, from my testing it seems that we would have to use both of these interfaces, since only using the former one won't suppress the error message about unable to search in user_home_dir_t directory.
>>  
>> > diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
>> > index 35f1476..d1bd453 100644
>> > --- a/policy/modules/system/userdomain.if
>> > +++ b/policy/modules/system/userdomain.if
>> > @@ -565,6 +565,8 @@ template(`userdom_common_user_template',`
>> >  	# to this one.
>> >  	seutil_dontaudit_signal_newrole($1_t)
>> >  
>> > +	vlock_run_vlock($1_t,$1_r)
>> > +
>>  
>> Ithink we usually call "run" interfaces and role interfaces from the userdomain modules in the role layer instead. So suggest you add it to unprivuser.te, staff.te and sysadm.te instead
>> 
>>
>  ; [H]: I understand and I am ok with it, since it will provide a finer control of what user would be allowed to use the vlock program, rather than allowing all users in a "once-and-for-all" way :-P
>> 
>> Best regards,
>> Harry
>> 
>>  
>> >  	tunable_policy(`user_direct_mouse',`
>> >  		dev_read_mouse($1_t)
>> >  	')
>> > -- 
>> > 1.7.0.4
>> > 
>>  
>> > _______________________________________________
>> > refpolicy mailing list
>> > refpolicy at oss.tresys.com
>> > http://oss.tresys.com/mailman/listinfo/refpolicy
>>  
>> 
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy 		 	   	
>  	  
>  
>> From d556d45ef92db34b0d3ea6fba27895eee2295798 Mon Sep 17 00:00:00 2001
>> From: Harry Ciao <qingtao.cao@windriver.com>
>> Date: Tue, 26 Oct 2010 14:34:11 +0800
>> Subject: [v2 PATCH 1/1] Adding support for the vlock program.
>> 
>> Adding support for the vlock program, which is to lock one or more
>> sessions on the console.
>> 
>> Both system administrator and unprivileged user could use vlock
>> to lock his current console when logging in from the serial console
>> or by ssh.
>> 
>> Signed-off-by: Harry Ciao <harrytaurus2002@hotmail.com>
>> ---
>>  policy/modules/apps/vlock.fc       |    1 +
>>  policy/modules/apps/vlock.if       |   46 ++++++++++++++++++++++++++++
>>  policy/modules/apps/vlock.te       |   58 ++++++++++++++++++++++++++++++++++++
>>  policy/modules/roles/staff.te      |    4 ++
>>  policy/modules/roles/sysadm.te     |    3 ++
>>  polic
>  y/modules/roles/unprivuser.te |    4 ++
>>  6 files changed, 116 insertions(+), 0 deletions(-)
>>  create mode 100644 policy/modules/apps/vlock.fc
>>  create mode 100644 policy/modules/apps/vlock.if
>>  create mode 100644 policy/modules/apps/vlock.te
>> 
>> diff --git a/policy/modules/apps/vlock.fc b/policy/modules/apps/vlock.fc
>> new file mode 100644
>> index 0000000..621d5fd
>> --- /dev/null
>> +++ b/policy/modules/apps/vlock.fc
>> @@ -0,0 +1 @@
>> +/usr/sbin/vlock-main	--	gen_context(system_u:object_r:vlock_exec_t,s0)
>> diff --git a/policy/modules/apps/vlock.if b/policy/modules/apps/vlock.if
>> new file mode 100644
>> index 0000000..264293a
>> --- /dev/null
>> +++ b/policy/modules/apps/vlock.if
>> @@ -0,0 +1,46 @@
>> +## <summary>Lock one or more sessions on the Linux console.</summary>
>> +
>> +#######################################
>> +## <summa
>  ry>
>> +## 	Execute vlock in the vlock domain.
>> +## </summary>
>> +## <param name="domain">
>> +##	<summary>
>> +##	Domain allowed to transition.
>> +##	</summary>
>> +## </param>
>> +#
>> +interface(`vlock_domtrans_vlock',`
>> +	gen_require(`
>> +		type vlock_t, vlock_exec_t;
>> +	')
>> +
>> +	corecmd_search_bin($1)
>> +	domtrans_pattern($1, vlock_exec_t, vlock_t)
>> +')
>> +
>> +########################################
>> +## <summary>
>> +##	Execute vlock in the vlock domain, and
>> +##	allow the specified role the vlock domain.
>> +## </summary>
>> +## <param name="domain">
>> +##	<summary>
>> +##	Domain allowed to transition.
>> +##	</summary>
>> +## </param>
>> +## <param name="role">
>> +##	<summary>
>> +##	Role allowed to access.
>> +
>  ##	</summary>
>> +## </param>
>> +## <rolecap/>
>> +#
>> +interface(`vlock_run_vlock',`
>> +	gen_require(`
>> +		type vlock_t;
>> +	')
>> +
>> +	vlock_domtrans_vlock($1)
>> +	role $2 types vlock_t;
>> +')
>> diff --git a/policy/modules/apps/vlock.te b/policy/modules/apps/vlock.te
>> new file mode 100644
>> index 0000000..651ffb7
>> --- /dev/null
>> +++ b/policy/modules/apps/vlock.te
>> @@ -0,0 +1,58 @@
>> +policy_module(vlock, 1.0.0)
>> +
>> +########################################
>> +#
>> +# Declarations
>> +#
>> +
>> +type vlock_t;
>> +type vlock_exec_t;
>> +application_domain(vlock_t,vlock_exec_t)
>> +
>> +
>> +########################################
>> +#
>> +# Vlock local policy
>> +#
>> +
>> +# dont audit the failed attempt of vlock_t to setuid/setgid, because
>> +# 1. we 
>  used --enable-pam for vlock to use PAM to authenticate passwd
>> +# 2. no guarantee that making vlock setuid is safe
>> +dontaudit vlock_t self:capability { setuid setgid };
>> +allow vlock_t self:fd use;
>> +allow vlock_t self:fifo_file rw_fifo_file_perms;
>> +allow vlock_t self:unix_dgram_socket { create connect };
>> +allow vlock_t self:netlink_audit_socket { create_netlink_socket_perms nlmsg_relay };
>> +
>> +kernel_read_system_state(vlock_t)
>> +
>> +corecmd_list_bin(vlock_t)
>> +corecmd_read_bin_symlinks(vlock_t)
>> +
>> +init_dontaudit_rw_utmp(vlock_t)
>> +
>> +term_use_all_user_ttys(vlock_t)
>> +term_use_all_user_ptys(vlock_t)
>> +userdom_use_user_terminals(vlock_t)
>> +
>> +# Must call this interface otherwise PAM session will fail
>> +# with message of "terminal=? res=failed"
>> +domain_use_interactive_fds(vlock_t)
>> +
>> +auth_domtrans_chk_passwd(vloc
>  k_t)
>> +
>> +miscfiles_read_localization(vlock_t)
>> +
>> +logging_send_syslog_msg(vlock_t)
>> +
>> +selinux_dontaudit_getattr_fs(vlock_t)
>> +
>> +# pam_tally2 module could be used by vlock for authentication,
>> +# /var/log/tallylog's SL is usually s0, while the caller's SL could
>> +# be higher than s0.
>> +ifdef(`enable_mls',`
>> +	mls_file_write_all_levels(vlock_t)
>> +')
>> +
>> +files_dontaudit_search_home(vlock_t)
>> +userdom_dontaudit_search_user_home_dirs(vlock_t)
>> diff --git a/policy/modules/roles/staff.te b/policy/modules/roles/staff.te
>> index e0e2550..02bd117 100644
>> --- a/policy/modules/roles/staff.te
>> +++ b/policy/modules/roles/staff.te
>> @@ -168,3 +168,7 @@ ifndef(`distro_redhat',`
>>  		wireshark_role(staff_r, staff_t)
>>  	')
>>  ')
>> +
>> +optional_policy(`
>> +	vlock_run_vlock(staff_t, staff_r)
>> +')
>>
>  ; diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te
>> index 6b54416..da32021 100644
>> --- a/policy/modules/roles/sysadm.te
>> +++ b/policy/modules/roles/sysadm.te
>> @@ -446,3 +446,6 @@ ifndef(`distro_redhat',`
>>  	')
>>  ')
>>  
>> +optional_policy(`
>> +	vlock_run_vlock(sysadm_t, sysadm_r)
>> +')
>> diff --git a/policy/modules/roles/unprivuser.te b/policy/modules/roles/unprivuser.te
>> index 183ea8e..6536648 100644
>> --- a/policy/modules/roles/unprivuser.te
>> +++ b/policy/modules/roles/unprivuser.te
>> @@ -149,3 +149,7 @@ ifndef(`distro_redhat',`
>>  		wireshark_role(user_r, user_t)
>>  	')
>>  ')
>> +
>> +optional_policy(`
>> +	vlock_run_vlock(user_t, user_r)
>> +')
>> -- 
>> 1.7.0.4
>> 
>  
> 
> 
> _______________________________________________ refpolicy mailing list
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com