Re: A question about allow_unconfined_mmap_low in f11 amd selinux
Daniel J Walsh dwalsh at redhat.com writes: definitely still getting the error with any Wine application with mmap_low_allowed set to 0. selinux-policy-3.6.32-41.fc12.noarch The name has changed between RHEL5 - allow_unconfined_mmap_low and F12 - mmap_low_allowed The meaning has also changed in RHEL5 unconfined domains are allowed to mmap_low if the boolean is set. vbetool and wine are allowed whether or not the boolean is set. In F12 No domains are allowed to mmap_low unless the boolean is set. If it is set wine, vbetool and unconfined domains are allowed to mmap_zero. One of you is running wine in RHEL5 which is allowed to mmap_zero without the boolean. We changed this in F12 so that wine will break without the boolean set. Thank you for that clarification Dan. By the way I entered a private ticket at the Crossover site (hence not publicly visible), and have been told that their devs are currently already looking at this issue to try to see if the problem can be worked around in a new version of Crossover, which will presumably also be made available to newer versions of wine if a solution can be found. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
Daniel J Walsh dwalsh at redhat.com writes: The name has changed between RHEL5 - allow_unconfined_mmap_low and F12 - mmap_low_allowed The meaning has also changed in RHEL5 unconfined domains are allowed to mmap_low if the boolean is set. vbetool and wine are allowed whether or not the boolean is set. In F12 No domains are allowed to mmap_low unless the boolean is set. If it is set wine, vbetool and unconfined domains are allowed to mmap_zero. One of you is running wine in RHEL5 which is allowed to mmap_zero without the boolean. We changed this in F12 so that wine will break without the boolean set. There is an interesting thing I just found - in F11 without the bool set I can run MS Word 2003 in Crossover (i.e. effectively wine) and open a .doc file without any AVC popping up. However from a webmail interface opened in Firefox, and clicking on a .doc attachment, trying to open it via an association link to Word 2003 in Crossover immediately gives an AVC denial for wine-preloader and suggests allowing the bool! However the file does seem to open nevertheless!! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On Thu, 2009-11-05 at 19:32 +, Mike Cloaked wrote: Mike Cloaked mike.cloaked at gmail.com writes: Daniel J Walsh dwalsh at redhat.com writes: On 11/04/2009 10:23 AM, mike cloaked wrote: By moving forward do you mean that one can, in f11, reset the original boolean and set boolean mmap_low_allowed instead, in a forthcoming policy update? Or is this a planned change coming for f12 but not yet policy in earlier versions? Thanks We have setroubleshoot plugins that explain exactly to the users what they need to do to turn make their wine apps run. Does the dereference fix in kernel-2.6.30.9-96.fc11 address the issue raised here or have I got this wrong? I am somewhat confused by the following - I thought that if mmap_min_addr was 0 then you are not vulnerable. I also thought that installing wine, OR Crossover would set it to zero. Only on Ubuntu and then I believe only WINE. We do not ever set/allow this by default (at least not that I know of, and if we do please let me know, I'll whack someone with a clue-by-four) I have Crossover installed and not wine, and just checked: [m...@home1 ~]$ cat /proc/sys/vm/mmap_min_addr 65536 This is an f11 box. I also set the boolean by doing # setsebool -P allow_unconfined_mmap_low 1 Bad news! For maximum protection would want that bool off. You do not want to ALLOW unconfined to mmap low memory. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On Mon, Nov 9, 2009 at 2:40 PM, Mike Cloaked mike.cloa...@gmail.com wrote: Eric Paris eparis at redhat.com writes: I have Crossover installed and not wine, and just checked: [mike at home1 ~]$ cat /proc/sys/vm/mmap_min_addr 65536 This is an f11 box. I also set the boolean by doing # setsebool -P allow_unconfined_mmap_low 1 Bad news! For maximum protection would want that bool off. You do not want to ALLOW unconfined to mmap low memory. -Eric Many thanks Eric - I just tried unsetting the boolean - # setsebool -P allow_unconfined_mmap_low 0 Excel and Word 2003 still run in Crossover after resetting it without AVCs popping up - I will unset it in the other machines where I have this also - I guess selinux policy may have changed so that setting it as I did originally is no longer necessary. Really? For me there is no allow_unconfined_mmap_low at all and I'm definitely still getting the error with any Wine application with mmap_low_allowed set to 0. selinux-policy-3.6.32-41.fc12.noarch -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On 11/09/2009 03:15 PM, Justin wrote: On Mon, Nov 9, 2009 at 2:40 PM, Mike Cloaked mike.cloa...@gmail.com wrote: Eric Paris eparis at redhat.com writes: I have Crossover installed and not wine, and just checked: [mike at home1 ~]$ cat /proc/sys/vm/mmap_min_addr 65536 This is an f11 box. I also set the boolean by doing # setsebool -P allow_unconfined_mmap_low 1 Bad news! For maximum protection would want that bool off. You do not want to ALLOW unconfined to mmap low memory. -Eric Many thanks Eric - I just tried unsetting the boolean - # setsebool -P allow_unconfined_mmap_low 0 Excel and Word 2003 still run in Crossover after resetting it without AVCs popping up - I will unset it in the other machines where I have this also - I guess selinux policy may have changed so that setting it as I did originally is no longer necessary. Really? For me there is no allow_unconfined_mmap_low at all and I'm definitely still getting the error with any Wine application with mmap_low_allowed set to 0. selinux-policy-3.6.32-41.fc12.noarch The name has changed between RHEL5 - allow_unconfined_mmap_low and F12 - mmap_low_allowed The meaning has also changed in RHEL5 unconfined domains are allowed to mmap_low if the boolean is set. vbetool and wine are allowed whether or not the boolean is set. In F12 No domains are allowed to mmap_low unless the boolean is set. If it is set wine, vbetool and unconfined domains are allowed to mmap_zero. One of you is running wine in RHEL5 which is allowed to mmap_zero without the boolean. We changed this in F12 so that wine will break without the boolean set. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
Mike Cloaked mike.cloaked at gmail.com writes: Daniel J Walsh dwalsh at redhat.com writes: On 11/04/2009 10:23 AM, mike cloaked wrote: By moving forward do you mean that one can, in f11, reset the original boolean and set boolean mmap_low_allowed instead, in a forthcoming policy update? Or is this a planned change coming for f12 but not yet policy in earlier versions? Thanks We have setroubleshoot plugins that explain exactly to the users what they need to do to turn make their wine apps run. Does the dereference fix in kernel-2.6.30.9-96.fc11 address the issue raised here or have I got this wrong? I am somewhat confused by the following - I thought that if mmap_min_addr was 0 then you are not vulnerable. I also thought that installing wine, OR Crossover would set it to zero. I have Crossover installed and not wine, and just checked: [m...@home1 ~]$ cat /proc/sys/vm/mmap_min_addr 65536 This is an f11 box. I also set the boolean by doing # setsebool -P allow_unconfined_mmap_low 1 Now I have lost track whether this means I am vulnerable or not? I understand that installing wine would set mmap_min_addr to zero and make the machine vulnerable but can someone clarify so that I no longer confused? Thanks. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On 11/03/2009 04:35 PM, Adam Jackson wrote: On Tue, 2009-11-03 at 21:31 +, Mike Cloaked wrote: For people running wine or Crossover and using MS Office 2003 and related codes it is necessary to do: # setsebool -P allow_unconfined_mmap_low 1 To prevent AVC denials. However there is recent publicity at http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ which highlights that there is still a vulnerability in the kernel if this is set. For people running f11 with this boolean set how can one run wine and still remain secure? i.e. what should an admin do to protect the system? You can't. If I'm being slightly less flip: run wine in a kvm instance with selinux disabled, forward X to the host. - ajax You can run with SELinux in enforcement. mmap_low_allowed is the name of the boolean moving forward. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Re: A question about allow_unconfined_mmap_low in f11 amd selinux
Daniel J Walsh dwalsh at redhat.com writes: You can run with SELinux in enforcement. mmap_low_allowed is the name of the boolean moving forward. By moving forward do you mean that one can, in f11, reset the original boolean and set boolean mmap_low_allowed instead, in a forthcoming policy update? Or is this a planned change coming for f12 but not yet policy in earlier versions? Thanks -- mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On 11/04/2009 10:23 AM, mike cloaked wrote: Daniel J Walsh dwalsh at redhat.com writes: You can run with SELinux in enforcement. mmap_low_allowed is the name of the boolean moving forward. By moving forward do you mean that one can, in f11, reset the original boolean and set boolean mmap_low_allowed instead, in a forthcoming policy update? Or is this a planned change coming for f12 but not yet policy in earlier versions? Thanks allow_unconfined_mmap_zero boolean meant to allow unconfined_domains to mmap_zero. vbetool_exec_t and wine_exec_t have this capability without the boolean. We have removed that altogether. Now out of the box NO apps will have the ability to mmap_zero. If you want to run wine or vbetool(Hopefully fixed soon) You will have to set the boolean. All unconfined_domains will continue then also have this access. This access has proven to be a critical security feature, and several kernel/root vulnerabilities will be prevented by turning this boolean off, with the only down side, preventing old windows applications from running by default in wine. (If vbetool is fixed). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On 11/04/2009 10:23 AM, mike cloaked wrote: Daniel J Walsh dwalsh at redhat.com writes: You can run with SELinux in enforcement. mmap_low_allowed is the name of the boolean moving forward. By moving forward do you mean that one can, in f11, reset the original boolean and set boolean mmap_low_allowed instead, in a forthcoming policy update? Or is this a planned change coming for f12 but not yet policy in earlier versions? Thanks We have setroubleshoot plugins that explain exactly to the users what they need to do to turn make their wine apps run. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
mmap_low_allowed is the name of the boolean moving forward.
This access has proven to be a critical security feature,
and several kernel/root vulnerabilities will be prevented
by turning this boolean off, with the only down side,
preventing old windows applications from running by default in wine.
(If vbetool is fixed).
It is a mistake to believe the only down side is preventing
old [W]indows applications from running by default in wine.
The claim is not true.
I have three applications that fundamentally fail to work
if mmap(0,PAGE_SIZE,,MAP_FIXED,,) is disallowed. Addressing
memory at address 0 is fundamental to the way that they work.
Using any other page would totally prevent two of the apps
from working at all, and would severely cripple the third.
They are not old [W]indows apps. They are every-day utilities
and development tools written for Linux, and I object to them
being broken.
The kernel could remove 99.9% of the vulnerability, with
no dynamic cost to processes that don't use page 0, by:
1. Reduce STACK_TOP by one page, and reserve the corresponding
virtual page frame.
2. If a process does mmap(0,,,MAP_FIXED,,) then turn on the
process status bit which forces slow path for kernel entry
via system call from that process. In the slow path, check for
a mapping at page 0 and if so then move that mapping to the
reserved page at STACK_TOP, and turn off the mapping at page 0.
Reverse the substitution when returning from the syscall.
3. Add the necessary check in the trap handler for
copy_{to,from}_user() to handle intended kernel access to page 0
(including I/O) by substituting the reserved page instead.
This would allow mmap(0,,,MAP_FIXED,,) yet still protect all
synchronous kernel execution. The only remaining window of
vulnerability is interrupt handlers. If an interrupt handler
is touching *any* user address space then the problems are more
serious than mmap(0).
--
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On Wed, 2009-11-04 at 08:38 -0800, John Reiser wrote:
The kernel could remove 99.9% of the vulnerability, with
no dynamic cost to processes that don't use page 0, by:
1. Reduce STACK_TOP by one page, and reserve the corresponding
virtual page frame.
2. If a process does mmap(0,,,MAP_FIXED,,) then turn on the
process status bit which forces slow path for kernel entry
via system call from that process. In the slow path, check for
a mapping at page 0 and if so then move that mapping to the
reserved page at STACK_TOP, and turn off the mapping at page 0.
Reverse the substitution when returning from the syscall.
3. Add the necessary check in the trap handler for
copy_{to,from}_user() to handle intended kernel access to page 0
(including I/O) by substituting the reserved page instead.
This would allow mmap(0,,,MAP_FIXED,,) yet still protect all
synchronous kernel execution. The only remaining window of
vulnerability is interrupt handlers. If an interrupt handler
is touching *any* user address space then the problems are more
serious than mmap(0).
That's an interesting thought, do you think you could code something
like that and post it to lkml? I certainly might get some traction.
-Eric
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On Wed, 2009-11-04 at 08:38 -0800, John Reiser wrote:
I have three applications that fundamentally fail to work
if mmap(0,PAGE_SIZE,,MAP_FIXED,,) is disallowed. Addressing
memory at address 0 is fundamental to the way that they work.
Using any other page would totally prevent two of the apps
from working at all, and would severely cripple the third.
They are not old [W]indows apps. They are every-day utilities
and development tools written for Linux, and I object to them
being broken.
You're saying you have apps that rely on being able to dereference the
zero page, and _not_ because the processor mode requires it? I thought
the vax died long ago.
The kernel could remove 99.9% of the vulnerability, with
no dynamic cost to processes that don't use page 0, by:
1. Reduce STACK_TOP by one page, and reserve the corresponding
virtual page frame.
2. If a process does mmap(0,,,MAP_FIXED,,) then turn on the
process status bit which forces slow path for kernel entry
via system call from that process. In the slow path, check for
a mapping at page 0 and if so then move that mapping to the
reserved page at STACK_TOP, and turn off the mapping at page 0.
Reverse the substitution when returning from the syscall.
3. Add the necessary check in the trap handler for
copy_{to,from}_user() to handle intended kernel access to page 0
(including I/O) by substituting the reserved page instead.
This would allow mmap(0,,,MAP_FIXED,,) yet still protect all
synchronous kernel execution. The only remaining window of
vulnerability is interrupt handlers. If an interrupt handler
is touching *any* user address space then the problems are more
serious than mmap(0).
The problem is that the address space doesn't change when in the
interrupt handler; the zero page will still be mapped, so if there's a
bug in the interrupt handler that would normally oops, well, now it
won't.
Yes, bugs like that _have_ been found. Pretty sure they've been
exploited in the wild too.
You could probably fix this by checking if the zero page is mapped at
any context switch into the kernel (including interrupt) and doing
mprotect(PROT_NONE) on it if so. This adds a small but more or less
fixed overhead on every interrupt, plus a fairly high overhead when an
interrupt fires while the zero-mapping process is running.
- ajax
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
You're saying you have apps that rely on being able to dereference the zero page, and _not_ because the processor mode requires it? I thought the vax died long ago. The apps were written intentionally to exploit being able to use page 0. It's significantly faster (a factor of 10 or more) and simpler (thousands of lines of code that aren't needed) and easier to use (x==y versus x==(y + k).) With an identity map the hardware already understands the app's abstraction. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On Tue, 2009-11-03 at 21:31 +, Mike Cloaked wrote: For people running wine or Crossover and using MS Office 2003 and related codes it is necessary to do: # setsebool -P allow_unconfined_mmap_low 1 To prevent AVC denials. However there is recent publicity at http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ which highlights that there is still a vulnerability in the kernel if this is set. For people running f11 with this boolean set how can one run wine and still remain secure? i.e. what should an admin do to protect the system? You can't. If I'm being slightly less flip: run wine in a kvm instance with selinux disabled, forward X to the host. - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
