Re: Still getting random execute permissions on shared libraries.

Re: Still getting random execute permissions on shared libraries.

[Stephen Smalley]

On Tue, 2004-11-23 at 21:04, Daniel J Walsh wrote:
> Trying to run java from within firefox is a disaster, Mozilla crashes.
> 
> allow user_mozilla_t ld_so_cache_t:file execute;
> allow user_mozilla_t lib_t:file execute; (Jar files)
> allow user_mozilla_t user_tmp_t:file execute;
> allow user_t ld_so_cache_t:file execute;
> allow user_t locale_t:file execute;

They aren't random.  As discussed previously here and on
fedora-selinux-list, execution of a legacy binary causes the
read_implies_exec behavior to be enabled for the process, so that
subsequent read requests are transparently mapped to read|execute.  This
was a change in the upstream kernel, not SELinux, and was to allow
introduction of NX support without breaking compatibility with legacy
binaries.  SELinux is merely checking permissions based on the
information supplied by the core kernel.

Your options are:
- get java rebuilt with a PT_GNU_STACK header so the kernel doesn't
treat it as a legacy binary (assuming that it doesn't assume that read
implies exec),
- change policy to allow execute permission in these cases (although it
would be preferable here to move java into its own domain in that case,
so that you only have to allow it these permissions and not the entire
user domain or mozilla domain).

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Still getting random execute permissions on shared libraries.

[Daniel J Walsh]

Stephen Smalley wrote:

>On Tue, 2004-11-23 at 21:04, Daniel J Walsh wrote:
>  
>
>>Trying to run java from within firefox is a disaster, Mozilla crashes.
>>
>>allow user_mozilla_t ld_so_cache_t:file execute;
>>allow user_mozilla_t lib_t:file execute; (Jar files)
>>allow user_mozilla_t user_tmp_t:file execute;
>>allow user_t ld_so_cache_t:file execute;
>>allow user_t locale_t:file execute;
>>    
>>
>
>They aren't random.  As discussed previously here and on
>fedora-selinux-list, execution of a legacy binary causes the
>read_implies_exec behavior to be enabled for the process, so that
>subsequent read requests are transparently mapped to read|execute.  This
>was a change in the upstream kernel, not SELinux, and was to allow
>introduction of NX support without breaking compatibility with legacy
>binaries.  SELinux is merely checking permissions based on the
>information supplied by the core kernel.
>
>Your options are:
>- get java rebuilt with a PT_GNU_STACK header so the kernel doesn't
>treat it as a legacy binary (assuming that it doesn't assume that read
>implies exec),
>- change policy to allow execute permission in these cases (although it
>would be preferable here to move java into its own domain in that case,
>so that you only have to allow it these permissions and not the entire
>user domain or mozilla domain).
>  
>
I can't do either.  We do not ship java jre.  It comes from Sun.  If 
someone out there could
ask them to build it with PT_GNU_STACK it would be helpful.

This is using java runtime environment so I don't believe there is any 
execing going on,  So my only
choice would be to allow mozilla these privs.  I added the following 
changes to make it work.

diff --exclude-from=exclude -N -u -r 
nsapolicy/macros/program/mozilla_macros.te 
policy-1.19.5/macros/program/mozilla_macros.te
--- nsapolicy/macros/program/mozilla_macros.te    2004-11-24 
07:00:51.000000000 -0500
+++ policy-1.19.5/macros/program/mozilla_macros.te    2004-11-24 
10:57:51.332334406 -0500
@@ -29,7 +29,8 @@
 
 allow $1_mozilla_t usr_t:{ lnk_file file } { getattr read };
 allow $1_mozilla_t var_lib_t:file { getattr read };
-allow $1_mozilla_t urandom_device_t:chr_file { getattr ioctl read };
+allow $1_mozilla_t { random_device_t urandom_device_t }:chr_file { 
getattr ioctl read append };
+
 allow $1_mozilla_t self:socket create_socket_perms;
 allow $1_mozilla_t self:file { getattr read };
 
@@ -117,8 +118,20 @@
 dontaudit $1_mozilla_t file_type:dir getattr;
 allow $1_mozilla_t self:sem create_sem_perms;
 
+ifdef(`userhelper.te', `
+domain_auto_trans($1_mozilla_t, userhelper_exec_t, $1_userhelper_t)
+')
 dontaudit $1_mozilla_t selinux_config_t:dir search;
 
+#
+# Rules needed to run java apps
+#
+allow $1_mozilla_t ld_so_cache_t:file execute;
+allow $1_mozilla_t locale_t:file execute;
+dontaudit $1_mozilla_t *:{ chr_file file } execute;
+dontaudit $1_t ld_so_cache_t:file execute;
+dontaudit $1_t locale_t:file execute;
+
 ifdef(`xdm.te', `
 allow $1_mozilla_t xdm_t:fifo_file { write read };
 allow $1_mozilla_t xdm_tmp_t:dir search;

diff --exclude-from=exclude -N -u -r nsapolicy/file_contexts/types.fc 
policy-1.19.5/file_contexts/types.fc
--- nsapolicy/file_contexts/types.fc    2004-11-24 07:00:50.000000000 -0500
+++ policy-1.19.5/file_contexts/types.fc    2004-11-24 
10:57:51.324335309 -0500
@@ -334,6 +334,9 @@
 /usr(/.*)?            system_u:object_r:usr_t
 /usr(/.*)?/lib(64)?(/.*)?    system_u:object_r:lib_t
 /usr(/.*)?/lib(64)?/.*\.so(\.[^/]*)*    --    system_u:object_r:shlib_t
+/usr(/.*)?/java/.*\.so(\.[^/]*)*    --    system_u:object_r:shlib_t
+/usr(/.*)?/java/.*\.jar    --    system_u:object_r:shlib_t
+/usr(/.*)?/java/.*\.jsa    --    system_u:object_r:shlib_t
 /usr(/.*)?/lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)* system_u:object_r:ld_so_t
 /usr(/.*)?/bin(/.*)?        system_u:object_r:bin_t
 /usr(/.*)?/Bin(/.*)?        system_u:object_r:bin_t

--
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: Still getting random execute permissions on shared libraries.

[Stephen Smalley]

On Wed, 2004-11-24 at 11:14, Daniel J Walsh wrote:
> This is using java runtime environment so I don't believe there is any 
> execing going on,  So my only
> choice would be to allow mozilla these privs.  I added the following 
> changes to make it work.

I think that read_implies_exec is only enabled upon exec of a binary
(from load_elf_binary).

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: Still getting random execute permissions on shared libraries.

[petre rodan]

[-- Attachment #1.1: Type: text/plain, Size: 1753 bytes --]


Hi Stephen,

Stephen Smalley wrote:
> On Tue, 2004-11-23 at 21:04, Daniel J Walsh wrote:
> 
>>Trying to run java from within firefox is a disaster, Mozilla crashes.
>>
>>allow user_mozilla_t ld_so_cache_t:file execute;
>>allow user_mozilla_t lib_t:file execute; (Jar files)
>>allow user_mozilla_t user_tmp_t:file execute;
>>allow user_t ld_so_cache_t:file execute;
>>allow user_t locale_t:file execute;
> 
> 
> They aren't random.  As discussed previously here and on
> fedora-selinux-list, execution of a legacy binary causes the
> read_implies_exec behavior to be enabled for the process, so that
> subsequent read requests are transparently mapped to read|execute.  This
> was a change in the upstream kernel, not SELinux, and was to allow
> introduction of NX support without breaking compatibility with legacy
> binaries.  SELinux is merely checking permissions based on the
> information supplied by the core kernel.
> 
> Your options are:
> - get java rebuilt with a PT_GNU_STACK header so the kernel doesn't
> treat it as a legacy binary (assuming that it doesn't assume that read
> implies exec),
> - change policy to allow execute permission in these cases (although it
> would be preferable here to move java into its own domain in that case,
> so that you only have to allow it these permissions and not the entire
> user domain or mozilla domain).

I made a patch to the kernel that reverts to the old behaviour. no more execs on random files.
I find that changing the policy to allow those execs is not a valid solution.

would it be feasible to send upstream a patch that would remove the 'exec on read' behaviour if the kernel has selinux capabilities?

bye,
peter

-- 
petre rodan
<kaiowas@gentoo.org>
Developer,
Hardened Gentoo Linux

[-- Attachment #1.2: mmap_oddity.diff --]
[-- Type: text/plain, Size: 515 bytes --]

--- linux-2.6.9.orig/mm/mmap.c	2004-11-11 20:18:36.436249280 +0200
+++ linux-2.6.9/mm/mmap.c	2004-11-11 20:20:47.863269336 +0200
@@ -790,10 +790,12 @@
 	 * (the exception is when the underlying filesystem is noexec
 	 *  mounted, in which case we dont add PROT_EXEC.)
 	 */
+	/*
+ 	// this breaks havoc on a SELinux system
 	if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
 		if (!(file && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC)))
 			prot |= PROT_EXEC;
-
+	*/
 	if (!len)
 		return addr;
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: Still getting random execute permissions on shared libraries.

[Valdis.Kletnieks]

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

On Fri, 26 Nov 2004 21:49:22 +0200, petre rodan said:

> I made a patch to the kernel that reverts to the old behaviour. no more execs on random files.
> I find that changing the policy to allow those execs is not a valid solution.

Why is fixing the policy not a valid solution?

> would it be feasible to send upstream a patch that would remove the 'exec on 
> read' behaviour if the kernel has selinux capabilities?

A Very Bad Idea.  Basically, you're disabling a good and reasonable security
measure entirely, just because you can't get it to work with a *legacy* binary
and another security measure..

If you *have* to do something like this, you should make it much more targeted,
so the test is "if kernel has selinux *and* the binary is flagged as a known
problem, *then* disable *for this process".

It's especially bad because you're turning off future security in order to
deal with *legacy* binaries.  What do you do if/when Java gets rebuilt with
a more recent toolchain that adds the PT_GNU_STACK header?  Then your problem
is solved the *right* way, but you're still turning off a security measure
for everything else needlessly.

That's something that's probably OK as a local patch while you find a better
way, but we certainly don't want it merged into upstream....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Still getting random execute permissions on shared libraries.

[petre rodan]

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

Valdis.Kletnieks@vt.edu wrote:
> On Fri, 26 Nov 2004 21:49:22 +0200, petre rodan said:
>>I made a patch to the kernel that reverts to the old behaviour. no more execs on random files.
>>I find that changing the policy to allow those execs is not a valid solution.
> 
> Why is fixing the policy not a valid solution?

I happen to use some proprietary software (think antiviruses, file integrity checkers, audit programs) that would have needed massive changes in the policy because of those execs.
it might take some time until those will be recompiled with a newer toolchain.

>>would it be feasible to send upstream a patch that would remove the 'exec on 
>>read' behaviour if the kernel has selinux capabilities?
> A Very Bad Idea.  Basically, you're disabling a good and reasonable security
> measure entirely, just because you can't get it to work with a *legacy* binary
> and another security measure..

those security measures were added somewhere in the rc stage of 2.6.9, a kernel that was badly needed because of the flaws it was fixing.
I needed a way to replicate the behavior of older kernels in order to keep the sanity of the system, so that patch seemed a quick solution (call it as you wish).
I agree now that it shouldn't be sent upstream, but if someone feels the need to solve <subj>, then it patching time :)

bye,
peter

-- 
petre rodan
<kaiowas@gentoo.org>
Developer,
Hardened Gentoo Linux

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: Still getting random execute permissions on shared libraries.

[Stephen Smalley]

On Fri, 2004-11-26 at 14:49, petre rodan wrote:
> I made a patch to the kernel that reverts to the old behaviour. no more execs on random files.
> I find that changing the policy to allow those execs is not a valid solution.
> 
> would it be feasible to send upstream a patch that would remove the 'exec on read' behaviour if the kernel has selinux capabilities?

Removing it completely would be a problem if you want to support any
binaries at all that are assuming that read implies exec.  
  
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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