diff mbox

Disable execmem for sparc

Message ID 1271335385.26565.28.camel@moss-pluto.epoch.ncsc.mil
State RFC
Delegated to: David Miller
Headers show

Commit Message

Stephen Smalley April 15, 2010, 12:43 p.m. UTC 
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=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?

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

Comments

David Miller April 15, 2010, 10:25 p.m. UTC | #1 
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.
--
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 April 16, 2010, 12:36 p.m. UTC | #2 
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?
David Miller April 19, 2010, 4:15 a.m. UTC | #3 
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!
--
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
Tom \"spot\" Callaway April 27, 2010, 3:34 p.m. UTC | #4 
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=1404 audit(1272381939.416:2): enforcing=1 old_enforcing=0
auid=4294967295 ses=4294967295
type=1403 audit(1272381940.696:3): policy loaded auid=4294967295
ses=4294967295
dracut: Switching root
type=1400 audit(1272381942.195:4): avc:  denied  { execmem } for
pid=1055 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type=1400 audit(1272381942.245:5): avc:  denied  { execmem } for
pid=1059 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type=1400 audit(1272381942.315:6): avc:  denied  { execmem } for
pid=1060 comm="hostname" scontext=system_u:system_r:hostname_t:s0
tcontext=system_u:system_r:hostname_t:s0 tclass=process
type=1400 audit(1272381942.356:7): avc:  denied  { execmem } for
pid=1050 comm="readahead-colle"
scontext=system_u:system_r:readahead_t:s0
tcontext=system_u:system_r:readahead_t:s0 tclass=process
type=1400 audit(1272381942.376:8): avc:  denied  { execmem } for
pid=1063 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type=1400 audit(1272381942.385:9): avc:  denied  { execmem } for
pid=1065 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type=1400 audit(1272381942.396:10): avc:  denied  { execmem } for
pid=1068 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type=1400 audit(1272381942.466:11): avc:  denied  { execmem } for
pid=1077 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=1400 audit(1272381946.637:20): avc:  denied  { execmem } for
pid=1332 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type=1400 audit(1272381946.637:21): avc:  denied  { execmem } for
pid=1333 comm="restorecon" scontext=system_u:system_r:setfiles_t:s0
tcontext=system_u:system_r:setfiles_t:s0 tclass=process
type=1400 audit(1272381946.654:22): avc:  denied  { execmem } for
pid=1334 comm="plymouth" scontext=system_u:system_r:plymouth_t:s0
tcontext=system_u:system_r:plymouth_t:s0 tclass=process
type=1400 audit(1272381946.687:23): avc:  denied  { execmem } for
pid=1337 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=1400 audit(1272381947.536:24): avc:  denied  { execmem } for
pid=1485 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type=1400 audit(1272381947.546:25): avc:  denied  { execmem } for
pid=1487 comm="restorecon" scontext=system_u:system_r:setfiles_t:s0
tcontext=system_u:system_r:setfiles_t:s0 tclass=process
type=1400 audit(1272381947.556:26): avc:  denied  { execmem } for
pid=1490 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type=1400 audit(1272381947.566:27): avc:  denied  { execmem } for
pid=1491 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type=1400 audit(1272381947.566:28): avc:  denied  { execmem } for
pid=1492 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type=1400 audit(1272381947.576:29): avc:  denied  { execmem } for
pid=1493 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=1400 audit(1272381951.656:71): avc:  denied  { execmem } for
pid=1755 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type=1400 audit(1272381951.726:72): avc:  denied  { execmem } for
pid=1761 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=1400 audit(1272381952.934:73): avc:  denied  { execmem } for
pid=1841 comm="mount" scontext=system_u:system_r:mount_t:s0
tcontext=system_u:system_r:mount_t:s0 tclass=process
type=1400 audit(1272381952.996:74): avc:  denied  { execmem } for
pid=1850 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type=1400 audit(1272381953.146:75): avc:  denied  { execmem } for
pid=1857 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type=1400 audit(1272381953.246:76): avc:  denied  { execmem } for
pid=1861 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=1400 audit(1272381953.286:77): avc:  denied  { execmem } for
pid=1868 comm="consoletype" scontext=system_u:system_r:consoletype_t:s0
tcontext=system_u:system_r:consoletype_t:s0 tclass=process
type=1400 audit(1272381953.456:78): avc:  denied  { execmem } for
pid=1877 comm="sendmail" scontext=system_u:system_r:sendmail_t:s0
tcontext=system_u:system_r:sendmail_t:s0 tclass=process
type=1400 audit(1272381953.464:79): avc:  denied  { execmem } for
pid=1878 comm="plymouth" scontext=system_u:system_r:plymouth_t:s0
tcontext=system_u:system_r:plymouth_t:s0 tclass=process
type=1400 audit(1272381953.506:80): avc:  denied  { execmem } for
pid=1882 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=1400 audit(1272381957.135:88): avc:  denied  { execmem } for
pid=1940 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type=1400 audit(1272381957.135:90): avc:  denied  { execmem } for
pid=1941 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type=1400 audit(1272381957.135:91): avc:  denied  { execmem } for
pid=1938 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type=1400 audit(1272381957.135:92): avc:  denied  { execmem } for
pid=1943 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type=1400 audit(1272381957.135:89): avc:  denied  { execmem } for
pid=1939 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type=1400 audit(1272381957.135:93): avc:  denied  { execmem } for
pid=1942 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=1400 audit(1272381957.145:94): avc:  denied  { execmem } for
pid=1944 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type=1400 audit(1272381957.145:95): avc:  denied  { execmem } for
pid=1945 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type=1400 audit(1272381957.145:96): avc:  denied  { execmem } for
pid=1946 comm="mingetty" scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=process
type=1400 audit(1272381957.145:97): avc:  denied  { execmem } for
pid=1947 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
--
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 April 27, 2010, 5:05 p.m. UTC | #5 
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=1404 audit(1272381939.416:2): enforcing=1 old_enforcing=0
> auid=4294967295 ses=4294967295
> type=1403 audit(1272381940.696:3): policy loaded auid=4294967295
> ses=4294967295
> dracut: Switching root
> type=1400 audit(1272381942.195:4): avc:  denied  { execmem } for
> pid=1055 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?
Tom \"spot\" Callaway April 27, 2010, 6:20 p.m. UTC | #6 
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
--
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
David Miller April 27, 2010, 6:47 p.m. UTC | #7 
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.
--
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
diff mbox

Patch

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);
 }