[refpolicy] Adding support for the vlock program

[refpolicy] Adding support for the vlock program

[TaurusHarry]

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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101026/421c29ec/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Adding-support-for-the-vlock-program.patch
Type: text/x-patch
Size: 4740 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101026/421c29ec/attachment.bin 

[refpolicy] Adding support for the vlock program

[Dominick Grift]

On Tue, Oct 26, 2010 at 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 +0800
> 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 

> +	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,
> +##	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)
> +
> +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_var_symlinks(vlock_t)

Any idea what generic var content it needs to read and why it is labeled with the generic var_t type?
> +
> +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

> +
> +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(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

> +
> +# 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/log/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?

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

> 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

>  	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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101026/4986d13b/attachment.bin 

[refpolicy] Adding support for the vlock program

[TaurusHarry]

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@gmail.com
To: refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Adding support for the vlock program

On Tue, Oct 26, 2010 at 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 +0800
> 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 domain,
> +##	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. 

> +
> +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_var_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
> +# with 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/log/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.
 
> +
> +# 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 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101028/4fc507bc/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2-Adding-support-for-the-vlock-program.patch
Type: text/x-patch
Size: 5174 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101028/4fc507bc/attachment.bin 

[refpolicy] Adding support for the vlock program

[Dominick Grift]

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 at 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 +0800
> > 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 domain,
> > +##	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_var_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
> > +# with 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/log/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 ++
>  policy/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>
> +
> +#######################################
> +## <summary>
> +## 	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(vlock_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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101028/acf89f1d/attachment-0001.bin 

[refpolicy] Adding support for the vlock program

[TaurusHarry]

Hi Dom and Christ,

The attached is the v3 vlock.pp compliant with refpolicy coding style, tests passed.

Is it good enough for upstream? :-)

Thanks a lot!

Best regards,
Harry



Date: Thu, 28 Oct 2010 10:54:42 +0200
From: domg472@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 at 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 +0800
> > 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 domain,
> > +##	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_var_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
> > +# with 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/log/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 ++
>  policy/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>
> +
> +#######################################
> +## <summary>
> +## 	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(vlock_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 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101030/62d5046a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v3-Adding-support-for-the-vlock-program.patch
Type: text/x-patch
Size: 5003 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101030/62d5046a/attachment-0001.bin 

[refpolicy] Adding support for the vlock program

[Christopher J. PeBenito]

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

[refpolicy] Adding support for the vlock program

[HarryCiao]

Hi Chris,

> Date: Mon, 1 Nov 2010 11:28:30 -0400
> From: cpebenito at tresys.com
> To: harrytaurus2002 at hotmail.com
> CC: domg472 at gmail.com; refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Adding support for the vlock program
> 
> 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?
> 

Many thanks for wrapping up the vlock.pp! I am very happy to get a chance to contribute something back to this mailing list.

Well, you've got me! Yes, we should have had the auditadm and secadm able to use the vlock program, along with sysadm, staff or unprivileged user. I used to call the vlock_run() in the userdom_common_user_template() (to grant access of vlock to all users in an once-and-for-all way), but got suggested that we should call the run interfaces in the roles/ layer, I just forgot to patch the auditadm and secadm to make them able to use vlock.

Well, please find the patch in the attachment, tests passed. Thanks again!

Best regards,
Harry


> 
> > 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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101102/b3ba51d5/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-auditadm-secadm-able-to-use-vlock.patch
Type: text/x-patch
Size: 1425 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101102/b3ba51d5/attachment-0001.bin 

[refpolicy] Adding support for the vlock program

[Dominick Grift]

On Tue, Nov 02, 2010 at 07:17:26AM +0000, HarryCiao wrote:
> 
> Hi Chris,
> 
> > Date: Mon, 1 Nov 2010 11:28:30 -0400
> > From: cpebenito at tresys.com
> > To: harrytaurus2002 at hotmail.com
> > CC: domg472 at gmail.com; refpolicy at oss.tresys.com
> > Subject: Re: [refpolicy] Adding support for the vlock program
> > 
> > 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?
> > 
> 
> Many thanks for wrapping up the vlock.pp! I am very happy to get a chance to contribute something back to this mailing list.
> 
> Well, you've got me! Yes, we should have had the auditadm and secadm able to use the vlock program, along with sysadm, staff or unprivileged user. I used to call the vlock_run() in the userdom_common_user_template() (to grant access of vlock to all users in an once-and-for-all way), but got suggested that we should call the run interfaces in the roles/ layer, I just forgot to patch the auditadm and secadm to make them able to use vlock.
> 
> Well, please find the patch in the attachment, tests passed. Thanks again!

I did not mention those "other" admins because in my vision those should not be login users in the first place.
> 
> Best regards,
> Harry
> 
> 
> > 
> > > 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
>  		 	   		  

> From 622139a4a94b45d818a52973f8f7c567ba6130bc Mon Sep 17 00:00:00 2001
> From: Harry Ciao <qingtao.cao@windriver.com>
> Date: Tue, 2 Nov 2010 12:20:27 +0800
> Subject: [v0 PATCH 1/1] Make auditadm & secadm able to use vlock
> 
> Make the auditadm and secadm able to use the vlock program.
> Also bump their module versions.
> 
> Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
> ---
>  policy/modules/roles/auditadm.te |    5 ++++-
>  policy/modules/roles/secadm.te   |    5 ++++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/policy/modules/roles/auditadm.te b/policy/modules/roles/auditadm.te
> index 252913b..d31b46d 100644
> --- a/policy/modules/roles/auditadm.te
> +++ b/policy/modules/roles/auditadm.te
> @@ -1,4 +1,4 @@
> -policy_module(auditadm, 2.1.0)
> +policy_module(auditadm, 2.1.1)
>  
>  ########################################
>  #
> @@ -60,3 +60,6 @@ optional_policy(`
>  	sysadm_role_change(auditadm_r)
>  ')
>  
> +optional_policy(`
> +        vlock_run(auditadm_t, auditadm_r)
> +')
> diff --git a/policy/modules/roles/secadm.te b/policy/modules/roles/secadm.te
> index ebe6a9c..fc875f7 100644
> --- a/policy/modules/roles/secadm.te
> +++ b/policy/modules/roles/secadm.te
> @@ -1,4 +1,4 @@
> -policy_module(secadm, 2.1.0)
> +policy_module(secadm, 2.1.1)
>  
>  ########################################
>  #
> @@ -71,3 +71,6 @@ optional_policy(`
>  	sysadm_role_change(secadm_r)
>  ')
>  
> +optional_policy(`
> +        vlock_run(secadm_t, secadm_r)
> +')
> -- 
> 1.7.0.4
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101102/5d3fc27c/attachment.bin 

[refpolicy] Adding support for the vlock program

[Christopher J. PeBenito]

On 11/02/10 03:53, Dominick Grift wrote:
> On Tue, Nov 02, 2010 at 07:17:26AM +0000, HarryCiao wrote:
>>
>> Hi Chris,
>>
>>> Date: Mon, 1 Nov 2010 11:28:30 -0400
>>> From: cpebenito at tresys.com
>>> To: harrytaurus2002 at hotmail.com
>>> CC: domg472 at gmail.com; refpolicy at oss.tresys.com
>>> Subject: Re: [refpolicy] Adding support for the vlock program
>>>
>>> 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?
>>>
>>
>> Many thanks for wrapping up the vlock.pp! I am very happy to get a chance to contribute something back to this mailing list.
>>
>> Well, you've got me! Yes, we should have had the auditadm and secadm able to use the vlock program, along with sysadm, staff or unprivileged user. I used to call the vlock_run() in the userdom_common_user_template() (to grant access of vlock to all users in an once-and-for-all way), but got suggested that we should call the run interfaces in the roles/ layer, I just forgot to patch the auditadm and secadm to make them able to use vlock.
>>
>> Well, please find the patch in the attachment, tests passed. Thanks again!
> 
> I did not mention those "other" admins because in my vision those should not be login users in the first place.

They still can run in the console if you newrole to them, so they could
still want to lock the console.

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

[refpolicy] Adding support for the vlock program

[Christopher J. PeBenito]

On 11/02/10 03:17, HarryCiao wrote:
> Hi Chris,
> 
>> Date: Mon, 1 Nov 2010 11:28:30 -0400
>> From: cpebenito at tresys.com
>> To: harrytaurus2002 at hotmail.com
>> CC: domg472 at gmail.com; refpolicy at oss.tresys.com
>> Subject: Re: [refpolicy] Adding support for the vlock program
>>
>> 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?
>>
> 
> Many thanks for wrapping up the vlock.pp! I am very happy to get a
> chance to contribute something back to this mailing list.
> 
> Well, you've got me! Yes, we should have had the auditadm and secadm
> able to use the vlock program, along wit h sysadm, staff or unprivileged
> user. I used to call the vlock_run() in the
> userdom_common_user_template() (to grant access of vlock to all users in
> an once-and-for-all way), but got suggested that we should call the run
> interfaces in the roles/ layer, I just forgot to patch the auditadm and
> secadm to make them able to use vlock.
> 
> Well, please find the patch in the attachment, tests passed. Thanks again!

Merged.  In the future, please do not change the module versions.  It
may cause your patch to unnecessarily fail to apply if another change is
made between the time your patch is created and when it is applied.

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

[refpolicy] Adding support for the vlock program

[Dominick Grift]

On Tue, Oct 26, 2010 at 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!

Some more pretty insignificant cosmetic suggestions inline.
> 
> Best regards,
> Harry
>  		 	   		  

> From ad4692423bcb1e10d5b9f146eab86de09b37dbb3 Mon Sep 17 00:00:00 2001
> From: Harry Ciao <qingtao.cao@windriver.com>
> Date: Tue, 26 Oct 2010 14:34:11 +0800
> 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>

Try to put something meaningful in the summary we already know its policy so thats redundant. try something like:

"Lock one or more sessions on the Linux console."

> +
> +#######################################
> +## <summary>
> +## 	Execute vlock in the vlock domain.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.

Domain allowed to transition.
> +##	</summary>
> +## </param>
> +#
> +interface(`vlock_domtrans_vlock',`
> +	gen_require(`
> +		type vlock_t, vlock_exec_t;
> +	')
> +
> +	files_search_usr($1)
> +	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,
> +##	and use the caller's terminal.

That use the callers terminal is not applicable here.

> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.

Again: Domain allowed to transition.
> +##	</summary>
> +## </param>
> +## <param name="role">
> +##	<summary>
> +##	The role to be allowed the vlock domain.

We currently use just: Role allowed 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..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 };
> +
> +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_var_symlinks(vlock_t)
> +
> +init_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(vlock_t)
> +
> +miscfiles_read_localization(vlock_t)
> +
> +logging_send_syslog_msg(vlock_t)
> +
> +selinux_getattr_fs(vlock_t)
> +
> +# 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/log/tallylog file which is s0.
> +mls_file_write_all_levels(vlock_t)
> +
> +# 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)
> 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)
> +
>  	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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101026/8e0bd33e/attachment.bin 

[refpolicy] Adding support for the vlock program

[TaurusHarry]

Hi Dom,

Many thanks for your reviewing my patch, I have integrated your suggestions and the attached is the v1 version for the vlock.pp.

Thanks again,
Harry



Date: Tue, 26 Oct 2010 14:41:31 +0200
From: domg472@gmail.com
To: refpolicy at oss.tresys.com
Subject: Re: [refpolicy] Adding support for the vlock program

On Tue, Oct 26, 2010 at 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!
 
Some more pretty insignificant cosmetic suggestions inline.
> 
> Best regards,
> Harry
>  		 	   		  
 
> From ad4692423bcb1e10d5b9f146eab86de09b37dbb3 Mon Sep 17 00:00:00 2001
> From: Harry Ciao <qingtao.cao@windriver.com>
> Date: Tue, 26 Oct 2010 14:34:11 +0800
> 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>
 
Try to put something meaningful in the summary we already know its policy so thats redundant. try something like:
 
"Lock one or more sessions on the Linux console."
 
> +
> +#######################################
> +## <summary>
> +## 	Execute vlock in the vlock domain.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
 
Domain allowed to transition.
> +##	</summary>
> +## </param>
> +#
> +interface(`vlock_domtrans_vlock',`
> +	gen_require(`
> +		type vlock_t, vlock_exec_t;
> +	')
> +
> +	files_search_usr($1)
> +	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,
> +##	and use the caller's terminal.
 
That use the callers terminal is not applicable here.
 
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
 
Again: Domain allowed to transition.
> +##	</summary>
> +## </param>
> +## <param name="role">
> +##	<summary>
> +##	The role to be allowed the vlock domain.
 
We currently use just: Role allowed 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..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 };
> +
> +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_var_symlinks(vlock_t)
> +
> +init_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(vlock_t)
> +
> +miscfiles_read_localization(vlock_t)
> +
> +logging_send_syslog_msg(vlock_t)
> +
> +selinux_getattr_fs(vlock_t)
> +
> +# 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/log/tallylog file which is s0.
> +mls_file_write_all_levels(vlock_t)
> +
> +# 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)
> 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)
> +
>  	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 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101027/1334d6f1/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Adding-support-for-the-vlock-program.patch
Type: text/x-patch
Size: 4774 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101027/1334d6f1/attachment.bin 

[refpolicy] Adding support for the vlock program

[Dominick Grift]

On 10/27/2010 10:58 AM, TaurusHarry wrote:
> 
> Hi Dom,
> 
> Many thanks for your reviewing my patch, I have integrated your suggestions and the attached is the v1 version for the vlock.pp.

looks like you have missed my first reply with suggestions:

http://oss.tresys.com/pipermail/refpolicy/2010-October/003425.html:


> Thanks again,
> Harry
> 
> 
> 
> Date: Tue, 26 Oct 2010 14:41:31 +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 at 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!
>  
> Some more pretty insignificant cosmetic suggestions inline.
>>
>> Best regards,
>> Harry
>>  		 	   		  
>  
>> From ad4692423bcb1e10d5b9f146eab86de09b37dbb3 Mon Sep 17 00:00:00 2001
>> From: Harry Ciao <qingtao.cao@windriver.com>
>> Date: Tue, 26 Oct 2010 14:34:11 +0800
>> 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>
>  
> Try to put something meaningful in the summary we already know its policy so thats redundant. try something like:
>  
> "Lock one or more sessions on the Linux console."
>  
>> +
>> +#######################################
>> +## <summary>
>> +## 	Execute vlock in the vlock domain.
>> +## </summary>
>> +## <param name="domain">
>> +##	<summary>
>> +##	Domain allowed access.
>  
> Domain allowed to transition.
>> +##	</summary>
>> +## </param>
>> +#
>> +interface(`vlock_domtrans_vlock',`
>> +	gen_require(`
>> +		type vlock_t, vlock_exec_t;
>> +	')
>> +
>> +	files_search_usr($1)
>> +	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,
>> +##	and use the caller's terminal.
>  
> That use the callers terminal is not applicable here.
>  
>> +## </summary>
>> +## <param name="domain">
>> +##	<summary>
>> +##	Domain allowed access.
>  
> Again: Domain allowed to transition.
>> +##	</summary>
>> +## </param>
>> +## <param name="role">
>> +##	<summary>
>> +##	The role to be allowed the vlock domain.
>  
> We currently use just: Role allowed 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..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 };
>> +
>> +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_var_symlinks(vlock_t)
>> +
>> +init_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(vlock_t)
>> +
>> +miscfiles_read_localization(vlock_t)
>> +
>> +logging_send_syslog_msg(vlock_t)
>> +
>> +selinux_getattr_fs(vlock_t)
>> +
>> +# 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/log/tallylog file which is s0.
>> +mls_file_write_all_levels(vlock_t)
>> +
>> +# 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)
>> 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)
>> +
>>  	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 		 	   		  


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101027/407058cb/attachment.bin