* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
@ 2010-03-25 20:24 ` David Miller
2010-03-25 20:48 ` Dennis Gilmore
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: David Miller @ 2010-03-25 20:24 UTC (permalink / raw)
To: sparclinux
From: "Tom \"spot\" Callaway" <tcallawa@redhat.com>
Date: Wed, 24 Mar 2010 17:52:57 -0400
> Attached is a patch which disables execmem for sparc. Without it,
> selinux does not work at all on SPARC64.
>
> This patch should be reasonably non-controversial, because this is
> already being done for PPC32.
>
> Tested-by: Tom "spot" Callaway <tcallawa@redhat.com> (Ultra 10, T5220)
> Dennis Gilmore <dgilmore@redhat.com>
> Signed-off-by: Tom "spot" Callaway <tcallawa@redhat.com>
What is the reason why it doesn't work, I'm just curious?
Is there some dependency upon executable stacks or executable data
segments always working? Why can't SELINUX protect be used with
that correctly?
And since we're touching selinux code we need to at a minimum
CC: them so they can have a look at your change.
--------------------
diff -up linux-2.6.32.noarch/security/selinux/hooks.c.mprotect-sparc linux-2.6.32.noarch/security/selinux/hooks.c
--- linux-2.6.32.noarch/security/selinux/hooks.c.mprotect-sparc 2010-03-10 08:28:20.957571926 -0500
+++ linux-2.6.32.noarch/security/selinux/hooks.c 2010-03-10 08:29:15.732698763 -0500
@@ -3010,7 +3010,7 @@ static int file_map_prot_check(struct fi
const struct cred *cred = current_cred();
int rc = 0;
-#ifndef CONFIG_PPC32
+#if !defined(CONFIG_PPC32) && !defined(CONFIG_SPARC)
if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) {
/*
* We are making executable an anonymous mapping or a
@@ -3082,7 +3082,7 @@ static int selinux_file_mprotect(struct
if (selinux_checkreqprot)
prot = reqprot;
-#ifndef CONFIG_PPC32
+#if !defined(CONFIG_PPC32) && !defined(CONFIG_SPARC)
if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
int rc = 0;
if (vma->vm_start >= vma->vm_mm->start_brk &&
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
2010-03-25 20:24 ` David Miller
@ 2010-03-25 20:48 ` Dennis Gilmore
2010-03-26 15:33 ` Stephen Smalley
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Dennis Gilmore @ 2010-03-25 20:48 UTC (permalink / raw)
To: sparclinux
[-- Attachment #1: Type: Text/Plain, Size: 3349 bytes --]
On Thursday 25 March 2010 03:24:58 pm David Miller wrote:
> From: "Tom \"spot\" Callaway" <tcallawa@redhat.com>
> Date: Wed, 24 Mar 2010 17:52:57 -0400
>
> > Attached is a patch which disables execmem for sparc. Without it,
> > selinux does not work at all on SPARC64.
> >
> > This patch should be reasonably non-controversial, because this is
> > already being done for PPC32.
> >
> > Tested-by: Tom "spot" Callaway <tcallawa@redhat.com> (Ultra 10, T5220)
> >
> > Dennis Gilmore <dgilmore@redhat.com>
> >
> > Signed-off-by: Tom "spot" Callaway <tcallawa@redhat.com>
>
> What is the reason why it doesn't work, I'm just curious?
>
> Is there some dependency upon executable stacks or executable data
> segments always working? Why can't SELINUX protect be used with
> that correctly?
what happens is that almost all binaries end up with execmem set and selinux
prevents them from running. the system fails to even get close to coming up
in a usable state
Dec 31 18:00:40 sparcbook kernel: type=1400 audit(8.160:3): avc: denied {
execmem } for pid=208 comm="consoletype"
scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
Dec 31 18:00:40 sparcbook kernel: type=1400 audit(8.315:4): avc: denied {
execmem } for pid=211 comm="hostname"
scontext=system_u:system_r:hostname_t:s0
tcontext=system_u:system_r:hostname_t:s0 tclass=process
Dec 31 18:00:40 sparcbook kernel: type=1400 audit(8.520:5): avc: denied {
execmem } for pid=213 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
Dec 31 18:00:40 sparcbook kernel: type=1400 audit(8.570:6): avc: denied {
execmem } for pid=203 comm="readahead-colle"
scontext=system_u:system_r:readahead_t:s0
tcontext=system_u:system_r:readahead_t:s0 tclass=process
is a small sample of the logs you get not everything fails but almost
everything
>
> And since we're touching selinux code we need to at a minimum
> CC: them so they can have a look at your change.
>
> --------------------
> diff -up linux-2.6.32.noarch/security/selinux/hooks.c.mprotect-sparc
> linux-2.6.32.noarch/security/selinux/hooks.c ---
> linux-2.6.32.noarch/security/selinux/hooks.c.mprotect-sparc 2010-03-10
> 08:28:20.957571926 -0500 +++
> linux-2.6.32.noarch/security/selinux/hooks.c 2010-03-10 08:29:15.732698763
> -0500 @@ -3010,7 +3010,7 @@ static int file_map_prot_check(struct fi
> const struct cred *cred = current_cred();
> int rc = 0;
>
> -#ifndef CONFIG_PPC32
> +#if !defined(CONFIG_PPC32) && !defined(CONFIG_SPARC)
> if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) {
> /*
> * We are making executable an anonymous mapping or a
> @@ -3082,7 +3082,7 @@ static int selinux_file_mprotect(struct
> if (selinux_checkreqprot)
> prot = reqprot;
>
> -#ifndef CONFIG_PPC32
> +#if !defined(CONFIG_PPC32) && !defined(CONFIG_SPARC)
> if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
> int rc = 0;
> if (vma->vm_start >= vma->vm_mm->start_brk &&
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
2010-03-25 20:24 ` David Miller
2010-03-25 20:48 ` Dennis Gilmore
@ 2010-03-26 15:33 ` Stephen Smalley
2010-03-26 16:26 ` Dennis Gilmore
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Stephen Smalley @ 2010-03-26 15:33 UTC (permalink / raw)
To: sparclinux
On Thu, 2010-03-25 at 15:48 -0500, Dennis Gilmore wrote:
> On Thursday 25 March 2010 03:24:58 pm David Miller wrote:
> > From: "Tom \"spot\" Callaway" <tcallawa@redhat.com>
> > Date: Wed, 24 Mar 2010 17:52:57 -0400
> >
> > > Attached is a patch which disables execmem for sparc. Without it,
> > > selinux does not work at all on SPARC64.
> > >
> > > This patch should be reasonably non-controversial, because this is
> > > already being done for PPC32.
> > >
> > > Tested-by: Tom "spot" Callaway <tcallawa@redhat.com> (Ultra 10, T5220)
> > >
> > > Dennis Gilmore <dgilmore@redhat.com>
> > >
> > > Signed-off-by: Tom "spot" Callaway <tcallawa@redhat.com>
> >
> > What is the reason why it doesn't work, I'm just curious?
> >
> > Is there some dependency upon executable stacks or executable data
> > segments always working? Why can't SELINUX protect be used with
> > that correctly?
>
> what happens is that almost all binaries end up with execmem set and selinux
> prevents them from running. the system fails to even get close to coming up
> in a usable state
>
> Dec 31 18:00:40 sparcbook kernel: type\x1400 audit(8.160:3): avc: denied {
> execmem } for pid 8 comm="consoletype"
> scontext=system_u:system_r:consoletype_t:s0
> tcontext=system_u:system_r:consoletype_t:s0 tclass=process
> Dec 31 18:00:40 sparcbook kernel: type\x1400 audit(8.315:4): avc: denied {
> execmem } for pid!1 comm="hostname"
> scontext=system_u:system_r:hostname_t:s0
> tcontext=system_u:system_r:hostname_t:s0 tclass=process
> Dec 31 18:00:40 sparcbook kernel: type\x1400 audit(8.520:5): avc: denied {
> execmem } for pid!3 comm="mount" scontext=system_u:system_r:mount_t:s0
> tcontext=system_u:system_r:mount_t:s0 tclass=process
> Dec 31 18:00:40 sparcbook kernel: type\x1400 audit(8.570:6): avc: denied {
> execmem } for pid 3 comm="readahead-colle"
> scontext=system_u:system_r:readahead_t:s0
> tcontext=system_u:system_r:readahead_t:s0 tclass=process
>
> is a small sample of the logs you get not everything fails but almost
> everything
I think we need to understand why this is happening - it usually
reflects a toolchain problem (that was the case in the ppc32 situation,
and was later fixed in Fedora through an updated toolchain and rebuilt
userland). eu-readelf -l /bin/hostname shows what?
> >
> > And since we're touching selinux code we need to at a minimum
> > CC: them so they can have a look at your change.
> >
> > --------------------
> > diff -up linux-2.6.32.noarch/security/selinux/hooks.c.mprotect-sparc
> > linux-2.6.32.noarch/security/selinux/hooks.c ---
> > linux-2.6.32.noarch/security/selinux/hooks.c.mprotect-sparc 2010-03-10
> > 08:28:20.957571926 -0500 +++
> > linux-2.6.32.noarch/security/selinux/hooks.c 2010-03-10 08:29:15.732698763
> > -0500 @@ -3010,7 +3010,7 @@ static int file_map_prot_check(struct fi
> > const struct cred *cred = current_cred();
> > int rc = 0;
> >
> > -#ifndef CONFIG_PPC32
> > +#if !defined(CONFIG_PPC32) && !defined(CONFIG_SPARC)
> > if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) {
> > /*
> > * We are making executable an anonymous mapping or a
> > @@ -3082,7 +3082,7 @@ static int selinux_file_mprotect(struct
> > if (selinux_checkreqprot)
> > prot = reqprot;
> >
> > -#ifndef CONFIG_PPC32
> > +#if !defined(CONFIG_PPC32) && !defined(CONFIG_SPARC)
> > if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
> > int rc = 0;
> > if (vma->vm_start >= vma->vm_mm->start_brk &&
> > --
> > To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Stephen Smalley
National Security Agency
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (2 preceding siblings ...)
2010-03-26 15:33 ` Stephen Smalley
@ 2010-03-26 16:26 ` Dennis Gilmore
2010-04-08 5:03 ` David Miller
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Dennis Gilmore @ 2010-03-26 16:26 UTC (permalink / raw)
To: sparclinux
[-- Attachment #1: Type: Text/Plain, Size: 5397 bytes --]
On Friday 26 March 2010 10:33:50 am Stephen Smalley wrote:
> On Thu, 2010-03-25 at 15:48 -0500, Dennis Gilmore wrote:
> > On Thursday 25 March 2010 03:24:58 pm David Miller wrote:
> > > From: "Tom \"spot\" Callaway" <tcallawa@redhat.com>
> > > Date: Wed, 24 Mar 2010 17:52:57 -0400
> > >
> > > > Attached is a patch which disables execmem for sparc. Without it,
> > > > selinux does not work at all on SPARC64.
> > > >
> > > > This patch should be reasonably non-controversial, because this is
> > > > already being done for PPC32.
> > > >
> > > > Tested-by: Tom "spot" Callaway <tcallawa@redhat.com> (Ultra 10,
> > > > T5220)
> > > >
> > > > Dennis Gilmore <dgilmore@redhat.com>
> > > >
> > > > Signed-off-by: Tom "spot" Callaway <tcallawa@redhat.com>
> > >
> > > What is the reason why it doesn't work, I'm just curious?
> > >
> > > Is there some dependency upon executable stacks or executable data
> > > segments always working? Why can't SELINUX protect be used with
> > > that correctly?
> >
> > what happens is that almost all binaries end up with execmem set and
> > selinux prevents them from running. the system fails to even get close
> > to coming up in a usable state
> >
> > Dec 31 18:00:40 sparcbook kernel: type=1400 audit(8.160:3): avc: denied
> > { execmem } for pid=208 comm="consoletype"
> > scontext=system_u:system_r:consoletype_t:s0
> > tcontext=system_u:system_r:consoletype_t:s0 tclass=process
> > Dec 31 18:00:40 sparcbook kernel: type=1400 audit(8.315:4): avc: denied
> > { execmem } for pid=211 comm="hostname"
> > scontext=system_u:system_r:hostname_t:s0
> > tcontext=system_u:system_r:hostname_t:s0 tclass=process
> > Dec 31 18:00:40 sparcbook kernel: type=1400 audit(8.520:5): avc: denied
> > { execmem } for pid=213 comm="mount"
> > scontext=system_u:system_r:mount_t:s0
> > tcontext=system_u:system_r:mount_t:s0 tclass=process
> > Dec 31 18:00:40 sparcbook kernel: type=1400 audit(8.570:6): avc: denied
> > { execmem } for pid=203 comm="readahead-colle"
> > scontext=system_u:system_r:readahead_t:s0
> > tcontext=system_u:system_r:readahead_t:s0 tclass=process
> >
> > is a small sample of the logs you get not everything fails but almost
> > everything
>
> I think we need to understand why this is happening - it usually
> reflects a toolchain problem (that was the case in the ppc32 situation,
> and was later fixed in Fedora through an updated toolchain and rebuilt
> userland). eu-readelf -l /bin/hostname shows what?
eu-readelf -l /bin/hostname
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x00010034 0x00010034 0x000100 0x000100 R E 0x4
INTERP 0x000134 0x00010134 0x00010134 0x000013 0x000013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x00010000 0x00010000 0x002204 0x002204 R E 0x10000
LOAD 0x002204 0x00022204 0x00022204 0x000284 0x0002ac RWE 0x10000
DYNAMIC 0x002218 0x00022218 0x00022218 0x0000d0 0x0000d0 RW 0x4
NOTE 0x000148 0x00010148 0x00010148 0x000044 0x000044 R 0x4
GNU_EH_FRAME 0x002110 0x00012110 0x00012110 0x00003c 0x00003c R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x000000 0x000000 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 [RO: .interp]
02 [RO: .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym
.dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .text .fini
.rodata .eh_frame_hdr .eh_frame]
03 .ctors .dtors .jcr .dynamic .got .plt .data .bss
04 .dynamic
05 [RO: .note.ABI-tag .note.gnu.build-id]
06 [RO: .eh_frame_hdr]
07
>
> > > And since we're touching selinux code we need to at a minimum
> > > CC: them so they can have a look at your change.
> > >
> > > --------------------
> > > diff -up linux-2.6.32.noarch/security/selinux/hooks.c.mprotect-sparc
> > > linux-2.6.32.noarch/security/selinux/hooks.c ---
> > > linux-2.6.32.noarch/security/selinux/hooks.c.mprotect-sparc 2010-03-10
> > > 08:28:20.957571926 -0500 +++
> > > linux-2.6.32.noarch/security/selinux/hooks.c 2010-03-10
> > > 08:29:15.732698763 -0500 @@ -3010,7 +3010,7 @@ static int
> > > file_map_prot_check(struct fi
> > >
> > > const struct cred *cred = current_cred();
> > > int rc = 0;
> > >
> > > -#ifndef CONFIG_PPC32
> > > +#if !defined(CONFIG_PPC32) && !defined(CONFIG_SPARC)
> > >
> > > if ((prot & PROT_EXEC) && (!file || (!shared && (prot &
> > > PROT_WRITE)))) {
> > >
> > > /*
> > >
> > > * We are making executable an anonymous mapping or a
> > >
> > > @@ -3082,7 +3082,7 @@ static int selinux_file_mprotect(struct
> > >
> > > if (selinux_checkreqprot)
> > >
> > > prot = reqprot;
> > >
> > > -#ifndef CONFIG_PPC32
> > > +#if !defined(CONFIG_PPC32) && !defined(CONFIG_SPARC)
> > >
> > > if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
> > >
> > > int rc = 0;
> > > if (vma->vm_start >= vma->vm_mm->start_brk &&
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe sparclinux"
> > > in the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (3 preceding siblings ...)
2010-03-26 16:26 ` Dennis Gilmore
@ 2010-04-08 5:03 ` David Miller
2010-04-15 12:43 ` Stephen Smalley
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: David Miller @ 2010-04-08 5:03 UTC (permalink / raw)
To: sparclinux
Ping? We need to figure out why this is actually happening
instead of just blindly adding this ifdef and saying "oh well."
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (4 preceding siblings ...)
2010-04-08 5:03 ` David Miller
@ 2010-04-15 12:43 ` Stephen Smalley
2010-04-15 22:25 ` David Miller
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Stephen Smalley @ 2010-04-15 12:43 UTC (permalink / raw)
To: sparclinux
On Fri, 2010-03-26 at 11:33 -0400, Stephen Smalley wrote:
> On Thu, 2010-03-25 at 15:48 -0500, Dennis Gilmore wrote:
> > On Thursday 25 March 2010 03:24:58 pm David Miller wrote:
> > > From: "Tom \"spot\" Callaway" <tcallawa@redhat.com>
> > > Date: Wed, 24 Mar 2010 17:52:57 -0400
> > >
> > > > Attached is a patch which disables execmem for sparc. Without it,
> > > > selinux does not work at all on SPARC64.
> > > >
> > > > This patch should be reasonably non-controversial, because this is
> > > > already being done for PPC32.
> > > >
> > > > Tested-by: Tom "spot" Callaway <tcallawa@redhat.com> (Ultra 10, T5220)
> > > >
> > > > Dennis Gilmore <dgilmore@redhat.com>
> > > >
> > > > Signed-off-by: Tom "spot" Callaway <tcallawa@redhat.com>
> > >
> > > What is the reason why it doesn't work, I'm just curious?
> > >
> > > Is there some dependency upon executable stacks or executable data
> > > segments always working? Why can't SELINUX protect be used with
> > > that correctly?
> >
> > what happens is that almost all binaries end up with execmem set and selinux
> > prevents them from running. the system fails to even get close to coming up
> > in a usable state
> >
> > Dec 31 18:00:40 sparcbook kernel: type\x1400 audit(8.160:3): avc: denied {
> > execmem } for pid 8 comm="consoletype"
> > scontext=system_u:system_r:consoletype_t:s0
> > tcontext=system_u:system_r:consoletype_t:s0 tclass=process
> > Dec 31 18:00:40 sparcbook kernel: type\x1400 audit(8.315:4): avc: denied {
> > execmem } for pid!1 comm="hostname"
> > scontext=system_u:system_r:hostname_t:s0
> > tcontext=system_u:system_r:hostname_t:s0 tclass=process
> > Dec 31 18:00:40 sparcbook kernel: type\x1400 audit(8.520:5): avc: denied {
> > execmem } for pid!3 comm="mount" scontext=system_u:system_r:mount_t:s0
> > tcontext=system_u:system_r:mount_t:s0 tclass=process
> > Dec 31 18:00:40 sparcbook kernel: type\x1400 audit(8.570:6): avc: denied {
> > execmem } for pid 3 comm="readahead-colle"
> > scontext=system_u:system_r:readahead_t:s0
> > tcontext=system_u:system_r:readahead_t:s0 tclass=process
> >
> > is a small sample of the logs you get not everything fails but almost
> > everything
>
> I think we need to understand why this is happening - it usually
> reflects a toolchain problem (that was the case in the ppc32 situation,
> and was later fixed in Fedora through an updated toolchain and rebuilt
> userland). eu-readelf -l /bin/hostname shows what?
(never received your reply but found it in the mailing list archives)
Your eu-readelf output showed why SELinux is checking execmem - the data
segment has flags RWE and thus a private file mapping is being created
with PROT_WRITE and PROT_EXEC. That's a problem with the compiler
toolchain - report it to them please. This was a problem with ppc32
binaries before secure-plt was introduced.
In the meantime, I'd be interested in knowing whether we truly need to
disable all of the exec* checking or if we can in fact just disable this
specific case, ala:
Re-enable full SELinux exec* checking on ppc32 since the compiler
toolchain has long since been fixed and userland has been rebuilt, and
introduce a special case for sparc that only disables the execmem check
for private file mappings but retains it for anonymous mappings and
retains the other exec* checks.
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 63c2d36..9a4d0e4 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3004,8 +3004,11 @@ static int file_map_prot_check(struct file *file, unsigned long prot, int shared
const struct cred *cred = current_cred();
int rc = 0;
-#ifndef CONFIG_PPC32
+#if defined(CONFIG_SPARC)
+ if ((prot & PROT_EXEC) && !file) {
+#else
if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) {
+#endif
/*
* We are making executable an anonymous mapping or a
* private file mapping that will also be writable.
@@ -3015,7 +3018,6 @@ static int file_map_prot_check(struct file *file, unsigned long prot, int shared
if (rc)
goto error;
}
-#endif
if (file) {
/* read access is always possible with a mapping */
@@ -3076,7 +3078,6 @@ static int selinux_file_mprotect(struct vm_area_struct *vma,
if (selinux_checkreqprot)
prot = reqprot;
-#ifndef CONFIG_PPC32
if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
int rc = 0;
if (vma->vm_start >= vma->vm_mm->start_brk &&
@@ -3099,7 +3100,6 @@ static int selinux_file_mprotect(struct vm_area_struct *vma,
if (rc)
return rc;
}
-#endif
return file_map_prot_check(vma->vm_file, prot, vma->vm_flags&VM_SHARED);
}
--
Stephen Smalley
National Security Agency
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (5 preceding siblings ...)
2010-04-15 12:43 ` Stephen Smalley
@ 2010-04-15 22:25 ` David Miller
2010-04-16 12:36 ` Stephen Smalley
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: David Miller @ 2010-04-15 22:25 UTC (permalink / raw)
To: sparclinux
From: Stephen Smalley <sds@tycho.nsa.gov>
Date: Thu, 15 Apr 2010 08:43:05 -0400
> Your eu-readelf output showed why SELinux is checking execmem - the data
> segment has flags RWE and thus a private file mapping is being created
> with PROT_WRITE and PROT_EXEC. That's a problem with the compiler
> toolchain - report it to them please. This was a problem with ppc32
> binaries before secure-plt was introduced.
I don't really intend to implement secure-plt any time soon on sparc
because there simply is no way to do it efficiently.
And when you talk about "toolchain issues" that all goes my way
anyways, so just direct such queries to me directly since I handle
both the kernel and toolchain bits entirely myself these days.
So you'll always have to deal with the PLT section on sparc having
write and execute permission.
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (6 preceding siblings ...)
2010-04-15 22:25 ` David Miller
@ 2010-04-16 12:36 ` Stephen Smalley
2010-04-19 4:15 ` David Miller
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Stephen Smalley @ 2010-04-16 12:36 UTC (permalink / raw)
To: sparclinux
On Thu, 2010-04-15 at 15:25 -0700, David Miller wrote:
> From: Stephen Smalley <sds@tycho.nsa.gov>
> Date: Thu, 15 Apr 2010 08:43:05 -0400
>
> > Your eu-readelf output showed why SELinux is checking execmem - the data
> > segment has flags RWE and thus a private file mapping is being created
> > with PROT_WRITE and PROT_EXEC. That's a problem with the compiler
> > toolchain - report it to them please. This was a problem with ppc32
> > binaries before secure-plt was introduced.
>
> I don't really intend to implement secure-plt any time soon on sparc
> because there simply is no way to do it efficiently.
>
> And when you talk about "toolchain issues" that all goes my way
> anyways, so just direct such queries to me directly since I handle
> both the kernel and toolchain bits entirely myself these days.
>
> So you'll always have to deal with the PLT section on sparc having
> write and execute permission.
Ok. Can someone with sparc hardware try the patch I posted to see if it
suffices?
--
Stephen Smalley
National Security Agency
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (7 preceding siblings ...)
2010-04-16 12:36 ` Stephen Smalley
@ 2010-04-19 4:15 ` David Miller
2010-04-27 15:34 ` Tom "spot" Callaway
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: David Miller @ 2010-04-19 4:15 UTC (permalink / raw)
To: sparclinux
From: Stephen Smalley <sds@tycho.nsa.gov>
Date: Fri, 16 Apr 2010 08:36:42 -0400
> On Thu, 2010-04-15 at 15:25 -0700, David Miller wrote:
>> From: Stephen Smalley <sds@tycho.nsa.gov>
>> Date: Thu, 15 Apr 2010 08:43:05 -0400
>>
>> > Your eu-readelf output showed why SELinux is checking execmem - the data
>> > segment has flags RWE and thus a private file mapping is being created
>> > with PROT_WRITE and PROT_EXEC. That's a problem with the compiler
>> > toolchain - report it to them please. This was a problem with ppc32
>> > binaries before secure-plt was introduced.
>>
>> I don't really intend to implement secure-plt any time soon on sparc
>> because there simply is no way to do it efficiently.
>>
>> And when you talk about "toolchain issues" that all goes my way
>> anyways, so just direct such queries to me directly since I handle
>> both the kernel and toolchain bits entirely myself these days.
>>
>> So you'll always have to deal with the PLT section on sparc having
>> write and execute permission.
>
> Ok. Can someone with sparc hardware try the patch I posted to see if it
> suffices?
Tom, please give Stephen's patch a test. Thanks!
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (8 preceding siblings ...)
2010-04-19 4:15 ` David Miller
@ 2010-04-27 15:34 ` Tom "spot" Callaway
2010-04-27 17:05 ` Stephen Smalley
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Tom "spot" Callaway @ 2010-04-27 15:34 UTC (permalink / raw)
To: sparclinux
On 04/16/2010 08:36 AM, Stephen Smalley wrote:
> On Thu, 2010-04-15 at 15:25 -0700, David Miller wrote:
>> From: Stephen Smalley <sds@tycho.nsa.gov>
>> Date: Thu, 15 Apr 2010 08:43:05 -0400
>>
>>> Your eu-readelf output showed why SELinux is checking execmem - the data
>>> segment has flags RWE and thus a private file mapping is being created
>>> with PROT_WRITE and PROT_EXEC. That's a problem with the compiler
>>> toolchain - report it to them please. This was a problem with ppc32
>>> binaries before secure-plt was introduced.
>>
>> I don't really intend to implement secure-plt any time soon on sparc
>> because there simply is no way to do it efficiently.
>>
>> And when you talk about "toolchain issues" that all goes my way
>> anyways, so just direct such queries to me directly since I handle
>> both the kernel and toolchain bits entirely myself these days.
>>
>> So you'll always have to deal with the PLT section on sparc having
>> write and execute permission.
>
> Ok. Can someone with sparc hardware try the patch I posted to see if it
> suffices?
Apologies for the delay. Your patch does not suffice.
With your patch applied, this is the result:
dracut: Mounted root filesystem /dev/mapper/vg_apollo-lv_root
dracut: Loading SELinux policy
type\x1404 audit(1272381939.416:2): enforcing=1 old_enforcing=0
auidB94967295 sesB94967295
type\x1403 audit(1272381940.696:3): policy loaded auidB94967295
sesB94967295
dracut: Switching root
type\x1400 audit(1272381942.195:4): avc: denied { execmem } for
pid\x1055 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type\x1400 audit(1272381942.245:5): avc: denied { execmem } for
pid\x1059 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type\x1400 audit(1272381942.315:6): avc: denied { execmem } for
pid\x1060 comm="hostname" scontext=system_u:system_r:hostname_t:s0
tcontext=system_u:system_r:hostname_t:s0 tclass=process
type\x1400 audit(1272381942.356:7): avc: denied { execmem } for
pid\x1050 comm="readahead-colle"
scontext=system_u:system_r:readahead_t:s0
tcontext=system_u:system_r:readahead_t:s0 tclass=process
type\x1400 audit(1272381942.376:8): avc: denied { execmem } for
pid\x1063 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type\x1400 audit(1272381942.385:9): avc: denied { execmem } for
pid\x1065 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type\x1400 audit(1272381942.396:10): avc: denied { execmem } for
pid\x1068 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type\x1400 audit(1272381942.466:11): avc: denied { execmem } for
pid\x1077 comm="restorecon" scontext=system_u:system_r:setfiles_t:s0
tcontext=system_u:system_r:setfiles_t:s0 tclass=process
udev: starting version 145
e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
e1000e: Copyright (c) 1999-2008 Intel Corporation.
0000:08:00.0: eth0: (PCI Express:2.5GB/s:Width x4) 00:14:4f:d4:8a:5a
0000:08:00.0: eth0: Intel(R) PRO/1000 Network Connection
0000:08:00.0: eth0: MAC: 0, PHY: 4, PBA No: ffffff-0ff
0000:08:00.1: eth1: (PCI Express:2.5GB/s:Width x4) 00:14:4f:d4:8a:5b
0000:08:00.1: eth1: Intel(R) PRO/1000 Network Connection
0000:08:00.1: eth1: MAC: 0, PHY: 4, PBA No: ffffff-0ff
0000:09:00.0: eth2: (PCI Express:2.5GB/s:Width x4) 00:14:4f:d4:8a:5c
0000:09:00.0: eth2: Intel(R) PRO/1000 Network Connection
0000:09:00.0: eth2: MAC: 0, PHY: 4, PBA No: ffffff-0ff
0000:09:00.1: eth3: (PCI Express:2.5GB/s:Width x4) 00:14:4f:d4:8a:5d
0000:09:00.1: eth3: Intel(R) PRO/1000 Network Connection
0000:09:00.1: eth3: MAC: 0, PHY: 4, PBA No: ffffff-0ff
__ratelimit: 24 callbacks suppressed
type\x1400 audit(1272381946.637:20): avc: denied { execmem } for
pid\x1332 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type\x1400 audit(1272381946.637:21): avc: denied { execmem } for
pid\x1333 comm="restorecon" scontext=system_u:system_r:setfiles_t:s0
tcontext=system_u:system_r:setfiles_t:s0 tclass=process
type\x1400 audit(1272381946.654:22): avc: denied { execmem } for
pid\x1334 comm="plymouth" scontext=system_u:system_r:plymouth_t:s0
tcontext=system_u:system_r:plymouth_t:s0 tclass=process
type\x1400 audit(1272381946.687:23): avc: denied { execmem } for
pid\x1337 comm="hostname" scontext=system_u:system_r:hostname_t:s0
tcontext=system_u:system_r:hostname_t:s0 tclass=process
device-mapper: multipath: version 1.1.0 loaded
type\x1400 audit(1272381947.536:24): avc: denied { execmem } for
pid\x1485 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type\x1400 audit(1272381947.546:25): avc: denied { execmem } for
pid\x1487 comm="restorecon" scontext=system_u:system_r:setfiles_t:s0
tcontext=system_u:system_r:setfiles_t:s0 tclass=process
type\x1400 audit(1272381947.556:26): avc: denied { execmem } for
pid\x1490 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type\x1400 audit(1272381947.566:27): avc: denied { execmem } for
pid\x1491 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type\x1400 audit(1272381947.566:28): avc: denied { execmem } for
pid\x1492 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type\x1400 audit(1272381947.576:29): avc: denied { execmem } for
pid\x1493 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
Adding 35241968k swap on /dev/mapper/vg_apollo-lv_swap. Priority:-1
extents:1 across:35241968k
__ratelimit: 123 callbacks suppressed
type\x1400 audit(1272381951.656:71): avc: denied { execmem } for
pid\x1755 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type\x1400 audit(1272381951.726:72): avc: denied { execmem } for
pid\x1761 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
type\x1400 audit(1272381952.934:73): avc: denied { execmem } for
pid\x1841 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type\x1400 audit(1272381952.996:74): avc: denied { execmem } for
pid\x1850 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type\x1400 audit(1272381953.146:75): avc: denied { execmem } for
pid\x1857 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type\x1400 audit(1272381953.246:76): avc: denied { execmem } for
pid\x1861 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process
type\x1400 audit(1272381953.286:77): avc: denied { execmem } for
pid\x1868 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type\x1400 audit(1272381953.456:78): avc: denied { execmem } for
pid\x1877 comm="sendmail" scontext=system_u:system_r:sendmail_t:s0
tcontext=system_u:system_r:sendmail_t:s0 tclass=process
type\x1400 audit(1272381953.464:79): avc: denied { execmem } for
pid\x1878 comm="plymouth" scontext=system_u:system_r:plymouth_t:s0
tcontext=system_u:system_r:plymouth_t:s0 tclass=process
type\x1400 audit(1272381953.506:80): avc: denied { execmem } for
pid\x1882 comm="restorecon" scontext=system_u:system_r:setfiles_t:s0
tcontext=system_u:system_r:setfiles_t:s0 tclass=process
__ratelimit: 21 callbacks suppressed
type\x1400 audit(1272381957.135:88): avc: denied { execmem } for
pid\x1940 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type\x1400 audit(1272381957.135:90): avc: denied { execmem } for
pid\x1941 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type\x1400 audit(1272381957.135:91): avc: denied { execmem } for
pid\x1938 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type\x1400 audit(1272381957.135:92): avc: denied { execmem } for
pid\x1943 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type\x1400 audit(1272381957.135:89): avc: denied { execmem } for
pid\x1939 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type\x1400 audit(1272381957.135:93): avc: denied { execmem } for
pid\x1942 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
init: tty4 main process (1938) terminated with status 127
init: tty4 main process ended, respawning
init: tty5 main process (1939) terminated with status 127
init: tty5 main process ended, respawning
init: tty2 main process (1940) terminated with status 127
init: tty2 main process ended, respawning
init: tty3 main process (1941) terminated with status 127
init: tty3 main process ended, respawning
init: tty1 main process (1942) terminated with status 127
init: tty1 main process ended, respawning
init: tty6 main process (1943) terminated with status 127
init: tty6 main process ended, respawning
type\x1400 audit(1272381957.145:94): avc: denied { execmem } for
pid\x1944 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type\x1400 audit(1272381957.145:95): avc: denied { execmem } for
pid\x1945 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type\x1400 audit(1272381957.145:96): avc: denied { execmem } for
pid\x1946 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type\x1400 audit(1272381957.145:97): avc: denied { execmem } for
pid\x1947 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
Init trails off and the system never goes anywhere.
~spot
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (9 preceding siblings ...)
2010-04-27 15:34 ` Tom "spot" Callaway
@ 2010-04-27 17:05 ` Stephen Smalley
2010-04-27 18:20 ` Tom "spot" Callaway
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Stephen Smalley @ 2010-04-27 17:05 UTC (permalink / raw)
To: sparclinux
On Tue, 2010-04-27 at 11:34 -0400, Tom "spot" Callaway wrote:
> On 04/16/2010 08:36 AM, Stephen Smalley wrote:
> > On Thu, 2010-04-15 at 15:25 -0700, David Miller wrote:
> >> From: Stephen Smalley <sds@tycho.nsa.gov>
> >> Date: Thu, 15 Apr 2010 08:43:05 -0400
> >>
> >>> Your eu-readelf output showed why SELinux is checking execmem - the data
> >>> segment has flags RWE and thus a private file mapping is being created
> >>> with PROT_WRITE and PROT_EXEC. That's a problem with the compiler
> >>> toolchain - report it to them please. This was a problem with ppc32
> >>> binaries before secure-plt was introduced.
> >>
> >> I don't really intend to implement secure-plt any time soon on sparc
> >> because there simply is no way to do it efficiently.
> >>
> >> And when you talk about "toolchain issues" that all goes my way
> >> anyways, so just direct such queries to me directly since I handle
> >> both the kernel and toolchain bits entirely myself these days.
> >>
> >> So you'll always have to deal with the PLT section on sparc having
> >> write and execute permission.
> >
> > Ok. Can someone with sparc hardware try the patch I posted to see if it
> > suffices?
>
> Apologies for the delay. Your patch does not suffice.
>
> With your patch applied, this is the result:
>
> dracut: Mounted root filesystem /dev/mapper/vg_apollo-lv_root
> dracut: Loading SELinux policy
> type\x1404 audit(1272381939.416:2): enforcing=1 old_enforcing=0
> auidB94967295 sesB94967295
> type\x1403 audit(1272381940.696:3): policy loaded auidB94967295
> sesB94967295
> dracut: Switching root
> type\x1400 audit(1272381942.195:4): avc: denied { execmem } for
> pid\x1055 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
> tcontext=system_u:system_r:consoletype_t:s0 tclass=process
<snip>
> Init trails off and the system never goes anywhere.
Ok, thanks for trying. Could you send a copy of /proc/pid/maps for one
of these processes that is triggering an execmem check?
--
Stephen Smalley
National Security Agency
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (10 preceding siblings ...)
2010-04-27 17:05 ` Stephen Smalley
@ 2010-04-27 18:20 ` Tom "spot" Callaway
2010-04-27 18:47 ` David Miller
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: Tom "spot" Callaway @ 2010-04-27 18:20 UTC (permalink / raw)
To: sparclinux
On 04/27/2010 01:05 PM, Stephen Smalley wrote:
> Ok, thanks for trying. Could you send a copy of /proc/pid/maps for one
> of these processes that is triggering an execmem check?
Mingetty seems like one of the few that is persistent. With the system
rebooted into a kernel with the original patch applied, and selinux
enabled, here's the info:
[spot@apollo ~]$ ps ax |grep minge
2174 tty4 Ss+ 0:00 /sbin/mingetty tty4
2175 tty5 Ss+ 0:00 /sbin/mingetty tty5
2176 tty2 Ss+ 0:00 /sbin/mingetty tty2
2177 tty3 Ss+ 0:00 /sbin/mingetty tty3
2178 tty1 Ss+ 0:00 /sbin/mingetty tty1
2179 tty6 Ss+ 0:00 /sbin/mingetty tty6
[root@apollo ~]$ cat /proc/2174/maps
00010000-00014000 r-xp 00000000 fd:00 15466577
/sbin/mingetty
00022000-00024000 rwxp 00002000 fd:00 15466577
/sbin/mingetty
00024000-00046000 rwxp 00000000 00:00 0
[heap]
f7d58000-f7ee2000 r-xp 00000000 fd:00 13893929
/lib/libc-2.11.1.so
f7ee2000-f7ef2000 ---p 0018a000 fd:00 13893929
/lib/libc-2.11.1.so
f7ef2000-f7ef4000 r--p 0018a000 fd:00 13893929
/lib/libc-2.11.1.so
f7ef4000-f7ef8000 rwxp 0018c000 fd:00 13893929
/lib/libc-2.11.1.so
f7ef8000-f7efa000 rwxp 00000000 00:00 0
f7efa000-f7efc000 rw-p 00000000 00:00 0
f7f12000-f7f14000 rw-p 00000000 00:00 0
f7f14000-f7f36000 r-xp 00000000 fd:00 13893922
/lib/ld-2.11.1.so
f7f44000-f7f46000 r--p 00020000 fd:00 13893922
/lib/ld-2.11.1.so
f7f46000-f7f48000 rwxp 00022000 fd:00 13893922
/lib/ld-2.11.1.so
ffacc000-ffaf6000 rw-p 00000000 00:00 0
[stack]
Please let me know if this is not what you needed.
~spot
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (11 preceding siblings ...)
2010-04-27 18:20 ` Tom "spot" Callaway
@ 2010-04-27 18:47 ` David Miller
2010-04-28 19:57 ` Stephen Smalley
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: David Miller @ 2010-04-27 18:47 UTC (permalink / raw)
To: sparclinux
From: "Tom \"spot\" Callaway" <tcallawa@redhat.com>
Date: Tue, 27 Apr 2010 14:20:21 -0400
> [root@apollo ~]$ cat /proc/2174/maps
> 00010000-00014000 r-xp 00000000 fd:00 15466577
> /sbin/mingetty
> 00022000-00024000 rwxp 00002000 fd:00 15466577
> /sbin/mingetty
> 00024000-00046000 rwxp 00000000 00:00 0
> [heap]
SELINUX probably barfs on the executable heap, the PLT is in the HEAP
just like powerpc32 and that's why VM_DATA_DEFAULT_FLAGS has to set
both executable and writable.
You also can't remove the CONFIG_PPC32 ifdefs in selinux, since
because of the VM_DATA_DEFAULT_FLAGS setting used still in that arch,
the heap will always have executable permission, just like sparc does.
You have to support those binaries forever, whether you like it or not.
Let's just replace the CONFIG_PPC32 ifdef in SELINUX with CONFIG_PPC32
|| CONFIG_SPARC as in Tom's original patch and let's be done with
this.
In fact I would go through all the arch/ header files and check the
VM_DATA_DEFAULT_FLAGS settings and add the necessary new ifdefs to the
SELINUX code so that other platforms don't have the pain of having to
go through this process too.
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (12 preceding siblings ...)
2010-04-27 18:47 ` David Miller
@ 2010-04-28 19:57 ` Stephen Smalley
2010-04-28 20:02 ` David Miller
2010-04-28 22:59 ` James Morris
15 siblings, 0 replies; 17+ messages in thread
From: Stephen Smalley @ 2010-04-28 19:57 UTC (permalink / raw)
To: sparclinux
On Tue, 2010-04-27 at 11:47 -0700, David Miller wrote:
> From: "Tom \"spot\" Callaway" <tcallawa@redhat.com>
> Date: Tue, 27 Apr 2010 14:20:21 -0400
>
> > [root@apollo ~]$ cat /proc/2174/maps
> > 00010000-00014000 r-xp 00000000 fd:00 15466577
> > /sbin/mingetty
> > 00022000-00024000 rwxp 00002000 fd:00 15466577
> > /sbin/mingetty
> > 00024000-00046000 rwxp 00000000 00:00 0
> > [heap]
>
> SELINUX probably barfs on the executable heap, the PLT is in the HEAP
> just like powerpc32 and that's why VM_DATA_DEFAULT_FLAGS has to set
> both executable and writable.
>
> You also can't remove the CONFIG_PPC32 ifdefs in selinux, since
> because of the VM_DATA_DEFAULT_FLAGS setting used still in that arch,
> the heap will always have executable permission, just like sparc does.
> You have to support those binaries forever, whether you like it or not.
>
> Let's just replace the CONFIG_PPC32 ifdef in SELINUX with CONFIG_PPC32
> || CONFIG_SPARC as in Tom's original patch and let's be done with
> this.
>
> In fact I would go through all the arch/ header files and check the
> VM_DATA_DEFAULT_FLAGS settings and add the necessary new ifdefs to the
> SELINUX code so that other platforms don't have the pain of having to
> go through this process too.
To avoid maintaining per-arch ifdefs, it seems that we could just
directly use (VM_DATA_DEFAULT_FLAGS & VM_EXEC) as the basis for deciding
whether to enable or disable these checks. VM_DATA_DEFAULT_FLAGS isn't
constant on some architectures but instead depends on
current->personality, but we want this applied uniformly. So we'll just
use the initial task state to determine whether or not to enable these
checks.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index ebee467..a03fd74 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2999,13 +2999,15 @@ static int selinux_file_ioctl(struct file *file, unsigned int cmd,
return file_has_perm(cred, file, av);
}
+static int default_noexec;
+
static int file_map_prot_check(struct file *file, unsigned long prot, int shared)
{
const struct cred *cred = current_cred();
int rc = 0;
-#ifndef CONFIG_PPC32
- if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) {
+ if (default_noexec &&
+ (prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) {
/*
* We are making executable an anonymous mapping or a
* private file mapping that will also be writable.
@@ -3015,7 +3017,6 @@ static int file_map_prot_check(struct file *file, unsigned long prot, int shared
if (rc)
goto error;
}
-#endif
if (file) {
/* read access is always possible with a mapping */
@@ -3076,8 +3077,8 @@ static int selinux_file_mprotect(struct vm_area_struct *vma,
if (selinux_checkreqprot)
prot = reqprot;
-#ifndef CONFIG_PPC32
- if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
+ if (default_noexec &&
+ (prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
int rc = 0;
if (vma->vm_start >= vma->vm_mm->start_brk &&
vma->vm_end <= vma->vm_mm->brk) {
@@ -3099,7 +3100,6 @@ static int selinux_file_mprotect(struct vm_area_struct *vma,
if (rc)
return rc;
}
-#endif
return file_map_prot_check(vma->vm_file, prot, vma->vm_flags&VM_SHARED);
}
@@ -5662,6 +5662,8 @@ static __init int selinux_init(void)
/* Set the security state for the initial task. */
cred_init_security();
+ default_noexec = !(VM_DATA_DEFAULT_FLAGS & VM_EXEC);
+
sel_inode_cache = kmem_cache_create("selinux_inode_security",
sizeof(struct inode_security_struct),
0, SLAB_PANIC, NULL);
--
Stephen Smalley
National Security Agency
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (13 preceding siblings ...)
2010-04-28 19:57 ` Stephen Smalley
@ 2010-04-28 20:02 ` David Miller
2010-04-28 22:59 ` James Morris
15 siblings, 0 replies; 17+ messages in thread
From: David Miller @ 2010-04-28 20:02 UTC (permalink / raw)
To: sparclinux
From: Stephen Smalley <sds@tycho.nsa.gov>
Date: Wed, 28 Apr 2010 15:57:57 -0400
> To avoid maintaining per-arch ifdefs, it seems that we could just
> directly use (VM_DATA_DEFAULT_FLAGS & VM_EXEC) as the basis for deciding
> whether to enable or disable these checks. VM_DATA_DEFAULT_FLAGS isn't
> constant on some architectures but instead depends on
> current->personality, but we want this applied uniformly. So we'll just
> use the initial task state to determine whether or not to enable these
> checks.
>
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH] Disable execmem for sparc
2010-03-24 21:52 [PATCH] Disable execmem for sparc Tom "spot" Callaway
` (14 preceding siblings ...)
2010-04-28 20:02 ` David Miller
@ 2010-04-28 22:59 ` James Morris
15 siblings, 0 replies; 17+ messages in thread
From: James Morris @ 2010-04-28 22:59 UTC (permalink / raw)
To: sparclinux
On Wed, 28 Apr 2010, Stephen Smalley wrote:
> To avoid maintaining per-arch ifdefs, it seems that we could just
> directly use (VM_DATA_DEFAULT_FLAGS & VM_EXEC) as the basis for deciding
> whether to enable or disable these checks. VM_DATA_DEFAULT_FLAGS isn't
> constant on some architectures but instead depends on
> current->personality, but we want this applied uniformly. So we'll just
> use the initial task state to determine whether or not to enable these
> checks.
>
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 17+ messages in thread