Supporting multiple python versions

Supporting multiple python versions

[Erich Schubert]

Hi,
Supporting multiple python versions is far from easy, as you might not
be aware of...

Python, when it encounters a .py file via "import", will try to compile
this file into a .pyc file residing in the same directory.
If it encounters an incompatible .pyc file, it will try to delete and
replace it. And of course different python versions may require
different .pyc files.

Most linux distributions try to precompile all .py files, to avoid .pyc
files being created by random processes when ran by root (users won't
have write permissions there).
However, if you have two python versions, that still might happen.

Debian therefore has moved the .pyc files to the /var/lib/python-support
directories, and a helper application that will precompile them for all
installed python versions (along with building an appropriate search
path)

However this means that many applications that so far only needed access
to usr_t will now need (read) access to var_lib_python_t.

Since these files are supposedly not secret, I'd be fine with allowing
any application access to them. They need a python interpreter running
to use them anyway, and python will want to read the .py file (which is
symlinked to the original one in /usr).

So what is the proper way of giving access to this type to "just about
every" domain? Or should we add an interface and try to find out which
domains need it?
I mean - bind doesn't need it. Samba shouldn't (except when someone
writes a password changing backend in python maybe). Apache probably
when mod_python is used...

best regards,
Erich Schubert
-- 
    erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
   It's not denial. I'm just selective about the reality I accept.   //\
      Mathematik ist die Kunst, verschiedene Dinge mit demselben     V_/_
                 Namen zu belegen. --- Henri Poincaré



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Supporting multiple python versions

[Russell Coker]

On Saturday 09 September 2006 01:31, Erich Schubert <erich@debian.org> wrote:
> Most linux distributions try to precompile all .py files, to avoid .pyc
> files being created by random processes when ran by root (users won't
> have write permissions there).
> However, if you have two python versions, that still might happen.
>
> Debian therefore has moved the .pyc files to the /var/lib/python-support
> directories, and a helper application that will precompile them for all
> installed python versions (along with building an appropriate search
> path)
>
> However this means that many applications that so far only needed access
> to usr_t will now need (read) access to var_lib_python_t.

One option is to relabel /var/lib/python-support as usr_t.  It's a little 
ugly, but I think that naming types after directories was a mistake anyway 
and this is just the symptom.

Another option is to have a new type python_compiled_t that can be used for 
all distributions.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Supporting multiple python versions

[Christopher J. PeBenito]

On Sat, 2006-09-09 at 11:16 +1000, Russell Coker wrote:
> On Saturday 09 September 2006 01:31, Erich Schubert <erich@debian.org> wrote:
> > However this means that many applications that so far only needed access
> > to usr_t will now need (read) access to var_lib_python_t.
> 
> One option is to relabel /var/lib/python-support as usr_t.  It's a little 
> ugly, but I think that naming types after directories was a mistake anyway 
> and this is just the symptom.

I agree on types like python_var_lib_t, but not something like usr_t
where the contents are so varied.

> Another option is to have a new type python_compiled_t that can be used for 
> all distributions.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Supporting multiple python versions

[Erich Schubert]

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

Hello Christopher,
Attached is my current version of adding python multiversion
precompilation support. It supports the multiversion case okay, but I
fear it doesn't support private modules yet.
Some applications, lets say mailman, won't be run with different python
versions. They'll always use the default python version (in constrast to
python libraries). These won't have their .pyc files
in /var/lib/python-support apparently...
But that would mean python-support also needs to be able to write /usr
(python-support is called during package installation or python upgrade;
lets say Debian switches /usr/bin/python from 2.4 to 2.5, then
upgrade-python-modules will recompile all private python modules).
Should we
- allow python-support to write usr_t (it's only run by dpkg_t or
sysadm_t, both of which can write usr_t anyway; no regular user should
be allowed into pythoncompile_t)
- make a file context like ^/usr/(.*)\.pyc$ -f as python_compiled_t and
add a filetrans rule usr_t python_compiled_t for pythoncompile_t?

best regards,
Erich Schubert
-- 
     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
  There is no branch of mathematics, however abstract, which may not  //\
 some day be applied to phenomena of the real world. --- Lobatchevsky V_/_
                Für jedes Problem gibt es eine Lösung,
                   die einfach, klar und falsch ist.

[-- Attachment #2: python-support.diff --]
[-- Type: text/x-patch, Size: 4732 bytes --]

Index: policy/modules/system/pythonsupport.fc
===================================================================
--- policy/modules/system/pythonsupport.fc	(Revision 0)
+++ policy/modules/system/pythonsupport.fc	(Revision 223)
@@ -0,0 +1,2 @@
+/usr/sbin/update-python-modules	--	gen_context(system_u:object_r:pythoncompile_exec_t,s0)
+/var/lib/python-support(/.*)?		gen_context(system_u:object_r:python_compiled_t,s0)
Index: policy/modules/system/userdomain.if
===================================================================
--- policy/modules/system/userdomain.if	(Revision 222)
+++ policy/modules/system/userdomain.if	(Revision 223)
@@ -835,6 +835,10 @@
 	')
 
 	optional_policy(`
+		pythonsupport_compiled_read($1_t)
+	')
+
+	optional_policy(`
 		quota_dontaudit_getattr_db($1_t)
 	')
 
Index: policy/modules/system/pythonsupport.te
===================================================================
--- policy/modules/system/pythonsupport.te	(Revision 0)
+++ policy/modules/system/pythonsupport.te	(Revision 223)
@@ -0,0 +1,44 @@
+policy_module(pythonsupport,0.0.1)
+
+########################################
+#
+# Declarations
+#
+
+type pythoncompile_t;
+type pythoncompile_exec_t;
+domain_type(pythoncompile_t)
+domain_entry_file(pythoncompile_t, pythoncompile_exec_t)
+
+role system_r types pythoncompile_t;
+role sysadm_r types pythoncompile_t;
+
+type python_compiled_t;
+files_type(python_compiled_t)
+
+########################################
+#
+# python-support local policy
+#
+
+kernel_read_system_state(pythoncompile_t)
+kernel_read_kernel_sysctls(pythoncompile_t)
+
+corecmd_exec_bin(pythoncompile_t)
+corecmd_exec_sbin(pythoncompile_t)
+
+files_read_etc_files(pythoncompile_t)
+files_read_usr_files(pythoncompile_t)
+
+libs_use_ld_so(pythoncompile_t)
+libs_use_shared_libs(pythoncompile_t)
+libs_use_lib_files(pythoncompile_t)
+
+miscfiles_read_localization(pythoncompile_t)
+
+
+# create compiled python modules
+allow pythoncompile_t python_compiled_t:dir manage_dir_perms;
+allow pythoncompile_t python_compiled_t:file manage_file_perms;
+allow pythoncompile_t python_compiled_t:lnk_file manage_file_perms;
+files_var_lib_filetrans(pythoncompile_t, python_compiled_t, dir)
Index: policy/modules/system/selinuxutil.te
===================================================================
--- policy/modules/system/selinuxutil.te	(Revision 222)
+++ policy/modules/system/selinuxutil.te	(Revision 223)
@@ -624,6 +624,10 @@
 	userdom_read_generic_user_home_content_files(semanage_t)
 ')
 
+optional_policy(`
+	pythonsupport_compiled_read(semanage_t)
+')
+
 ########################################
 #
 # Setfiles local policy
Index: policy/modules/system/pythonsupport.if
===================================================================
--- policy/modules/system/pythonsupport.if	(Revision 0)
+++ policy/modules/system/pythonsupport.if	(Revision 223)
@@ -0,0 +1,55 @@
+## <summary>Support for precompiling python modules</summary>
+## <desc>
+##	<p>
+##		Debians python-support will precompile installed python
+##		packages for installed python versions. This way,
+##		the python2.3-foobar and python2.4-foobar (and 2.5) packages
+##		could be merged into one python-foobar while keeping the
+##		dependency information useful.
+##	</p>
+## </desc>
+#
+
+########################################
+## <summary>
+##	Execute the python-support utility to precompile modules.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed to transition.
+##	</summary>
+## </param>
+#
+interface(`pythonsupport_domtrans',`
+	gen_require(`
+		type pythoncompile_t, pythoncompile_exec_t;
+	')
+
+	domain_auto_trans($1,pythoncompile_exec_t,pythoncompile_t)
+
+	allow $1 pythoncompile_t:fd use;
+	allow pythoncompile_t $1:fd use;
+	allow $1 pythoncompile_t:fifo_file rw_file_perms;
+	allow $1 pythoncompile_t:process sigchld;
+')
+
+########################################
+## <summary>
+##	Read compiled python modules
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed to read the compiled python modules.
+##	</summary>
+## </param>
+#
+interface(`pythonsupport_compiled_read',`
+	gen_require(`
+		type python_compiled_t;
+	')
+
+	files_search_var_lib($1)
+	allow $1 python_compiled_t:dir r_dir_perms;
+	allow $1 python_compiled_t:file r_file_perms;
+	allow $1 python_compiled_t:lnk_file r_file_perms;
+')
Index: policy/modules/admin/apt.te
===================================================================
--- policy/modules/admin/apt.te	(Revision 222)
+++ policy/modules/admin/apt.te	(Revision 223)
@@ -125,6 +125,10 @@
 #')
 
 optional_policy(`
+	pythonsupport_domtrans(apt_t)
+')
+
+optional_policy(`
 	# dpkg interaction
 	dpkg_read_db(apt_t)
 	dpkg_domtrans(apt_t)

Re: Supporting multiple python versions

[Russell Coker]

On Tuesday 12 September 2006 00:09, "Christopher J. PeBenito" 
<cpebenito@tresys.com> wrote:
> > One option is to relabel /var/lib/python-support as usr_t.  It's a little
> > ugly, but I think that naming types after directories was a mistake
> > anyway and this is just the symptom.
>
> I agree on types like python_var_lib_t, but not something like usr_t
> where the contents are so varied.

I think that Erich is on the right track here.  python_var_lib_t is not a good 
name as Fedora will use it for files under /usr.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.