Brad Spengler recently pointed out that the SELinux decision on how to
handle mmap_min_addr in some ways weakens system security vs on a system
without SELinux (and in other ways can be stronger). There is a trade
off and a reason I did what I did but I would like ideas and discussion
on how to get the best of both worlds.
With SELinux mapping the 0 page requires an SELinux policy permission,
mmap_zero. Without SELinux mapping the 0 page requires CAP_SYS_RAWIO.
Note that CAP_SYS_RAWIO roughly translates to uid=0 since noone really
does interesting things with capabilities.
The main problem is WINE. I'm told that WINE needs to map the 0 page to
support 16bit applications. On distros without SELinux users must
disable the mmap_min_addr protections for the ENTIRE system if they want
to run WINE.
http://wiki.winehq.org/PreloaderPageZeroProblem
I believe (from reading mailing lists) if you install WINE on ubuntu it
automatically disables these protections. Thus installing wine on
ubuntu disables ALL hardening gains of the mmap_min_addr.
On Fedora, with SELinux, we allow users to run WINE in a domain that has
the SELinux mmap_zero permission and thus other programs/domains, do not
have security weakened. Your daemons, like the web server, are still
unable to map the 0 page. This is different than distros without
SELinux, remember they have to disable protection globally.
But logged in users (by default), under SELinux, are 'unconfined' and
can by their very nature run their program in a domain that allows
mmap_zero. Trying to 'confine' the 'unconfined' user with SELinux is an
open problem which we don't currently even reasonably attempt address on
a broad scale. It's like besieging the user in a gentle mist of water
hoping they won't try to escape.
So in Fedora your web server is a harder entry point to exploit kernel
NULL pointer bugs, but you have no protections against a malicious user.
On Ubuntu if you install WINE your web server and your logged in users
have no hardening. If you do not install WINE non-root is hardened,
anything running as root is not (aka suid apps, aka pulseaudio).
So I was thinking today, wondering how to get the best (or at least
better) of both worlds on an SELinux system. I was considering adding a
second mmap_min_addr_lsm which would typically be equal to
mmap_min_addr. The purpose would be to allow the sysadmin to
individually control DAC/LSM protections. The security checks would
turn (sort of) into
if (addr < mmap_min_addr)
ret |= capable(CAP_SYS_RAWIO);
if (addr < mmap_min_addr_lsm)
ret |= [insert LSM check here]
So on a non-SELinux system users would end up with exactly what they
have today. if you want to run WINE as a normal user you have to set
mmap_min_addr = 0 and then you no longer need CAP_SYS_RAWIO. Not much
else we can do if your distro down support fine grained permissions.
On an SELinux system what this lets me do is default to a stricter
setup, one in which you have to have both CAP_SYS_RAWIO and the selinux
mmap_zero permission. You, out of the box, get protection for both your
malicious logged in user and your web server. Then if a user decides to
run WINE they would turn down mmap_min_addr. This would remove the
requirement that they are root, and leave the system vulnerable to a
malicious user, but would still allow SELinux to protect confined
domains and daemons.
Does anyone see a better way to let users continue to be users while
protecting most people? Yes SELinux is stronger in some areas than
without confining the ability to map the 0 page, but as has be rightly
pointed out it's foolish an broken that SELinux can weaken any
protections.
-Eric
On 07/20/2009 07:23 PM, Eric Paris wrote:
> Brad Spengler recently pointed out that the SELinux decision on how to
> handle mmap_min_addr in some ways weakens system security vs on a system
> without SELinux (and in other ways can be stronger). There is a trade
> off and a reason I did what I did but I would like ideas and discussion
> on how to get the best of both worlds.
>
> With SELinux mapping the 0 page requires an SELinux policy permission,
> mmap_zero. Without SELinux mapping the 0 page requires CAP_SYS_RAWIO.
> Note that CAP_SYS_RAWIO roughly translates to uid=0 since noone really
> does interesting things with capabilities.
>
> The main problem is WINE. I'm told that WINE needs to map the 0 page to
> support 16bit applications. On distros without SELinux users must
> disable the mmap_min_addr protections for the ENTIRE system if they want
> to run WINE.
>
> http://wiki.winehq.org/PreloaderPageZeroProblem
>
> I believe (from reading mailing lists) if you install WINE on ubuntu it
> automatically disables these protections. Thus installing wine on
> ubuntu disables ALL hardening gains of the mmap_min_addr.
>
> On Fedora, with SELinux, we allow users to run WINE in a domain that has
> the SELinux mmap_zero permission and thus other programs/domains, do not
> have security weakened. Your daemons, like the web server, are still
> unable to map the 0 page. This is different than distros without
> SELinux, remember they have to disable protection globally.
>
> But logged in users (by default), under SELinux, are 'unconfined' and
> can by their very nature run their program in a domain that allows
> mmap_zero. Trying to 'confine' the 'unconfined' user with SELinux is an
> open problem which we don't currently even reasonably attempt address on
> a broad scale. It's like besieging the user in a gentle mist of water
> hoping they won't try to escape.
>
> So in Fedora your web server is a harder entry point to exploit kernel
> NULL pointer bugs, but you have no protections against a malicious user.
> On Ubuntu if you install WINE your web server and your logged in users
> have no hardening. If you do not install WINE non-root is hardened,
> anything running as root is not (aka suid apps, aka pulseaudio).
>
> So I was thinking today, wondering how to get the best (or at least
> better) of both worlds on an SELinux system. I was considering adding a
> second mmap_min_addr_lsm which would typically be equal to
> mmap_min_addr. The purpose would be to allow the sysadmin to
> individually control DAC/LSM protections. The security checks would
> turn (sort of) into
>
> if (addr < mmap_min_addr)
> ret |= capable(CAP_SYS_RAWIO);
> if (addr < mmap_min_addr_lsm)
> ret |= [insert LSM check here]
>
> So on a non-SELinux system users would end up with exactly what they
> have today. if you want to run WINE as a normal user you have to set
> mmap_min_addr = 0 and then you no longer need CAP_SYS_RAWIO. Not much
> else we can do if your distro down support fine grained permissions.
>
> On an SELinux system what this lets me do is default to a stricter
> setup, one in which you have to have both CAP_SYS_RAWIO and the selinux
> mmap_zero permission. You, out of the box, get protection for both your
> malicious logged in user and your web server. Then if a user decides to
> run WINE they would turn down mmap_min_addr. This would remove the
> requirement that they are root, and leave the system vulnerable to a
> malicious user, but would still allow SELinux to protect confined
> domains and daemons.
>
> Does anyone see a better way to let users continue to be users while
> protecting most people? Yes SELinux is stronger in some areas than
> without confining the ability to map the 0 page, but as has be rightly
> pointed out it's foolish an broken that SELinux can weaken any
> protections.
>
> -Eric
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to [email protected] with
> the words "unsubscribe selinux" without quotes as the message.
If I'm not mistaken whats happening here is that some old 16 bit windows libraries have static addresses rather than pc offset or dynamically calculated ones. I don't think linux apps have ever done this so...
Beyond wine no other applications should use this.
The best solution would be to add code to wine which performs address recalculations either or the fly or at load time. Alternatively you could tell people who want 16 bit support to run wine or windows in a VM.
Or a boolean could be added to allow wine to support 16 bit applications which would allow it to do this, basically the same idea you had but in a way past selinux users might understand better then needing to set a system value. Make the default value off and tell users, you set this and your kernel may be compromised, try with it off first, run it in a VM and only if you absolutely have to should you allow this.
Christopher Pardy
On Mon, 20 Jul 2009 19:23:43 -0400
Eric Paris <[email protected]> wrote:
>
> Does anyone see a better way to let users continue to be users while
> protecting most people? Yes SELinux is stronger in some areas than
> without confining the ability to map the 0 page, but as has be rightly
> pointed out it's foolish an broken that SELinux can weaken any
> protections.
one option is to allow the page to be mapped, but only as
non-executable... in DOS that memory isn't where code lives anyway...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Mon, 20 Jul 2009, Eric Paris wrote:
> Does anyone see a better way to let users continue to be users while
> protecting most people? Yes SELinux is stronger in some areas than
> without confining the ability to map the 0 page, but as has be rightly
> pointed out it's foolish an broken that SELinux can weaken any
> protections.
I haven't seen a better idea so far.
I strongly believe that we need to maintain the principle, in SELinux and
LSM generally, that the interface is restrictive, i.e. that it can only
further restrict access. It should be impossible, from a design point of
view at least, for any LSM module to authorize more privilege than
standard DAC. This has always been a specific design goal of LSM. (The
capability module is an exception, as it has a fixed security policy and
implements legacy DAC behavior; there's no way to "fix" this).
In this case, we're not dealing with a standard form of access control,
where access to a userland object is being mediated. We're trying to
mediate the ability of a subject to bypass a separate mechanism which aims
to protect the kernel itself from attack via a more fundamental system
flaw. The LSM module didn't create that vulnerability directly, but it
must not allow the vulnerability to be more easily exploited.
The security policy writer should have a guarantee that the worst mistake
they can make is to mess up their own security model; if they can mess up
the base DAC security with MAC policy, we break that guarantee. There's
also an issue of user confidence in the LSM modules, in that they should
not be any worse off security-wise if they enable an enhanced protection
mechanism.
This does not account for kernel bugs in the LSM modules themselves,
obviously, but the same can be said for any kernel code, albeit with less
irony.
- James
--
James Morris
<[email protected]>
On Mon, Jul 20, 2009 at 07:23:43PM -0400, Eric Paris wrote:
> With SELinux mapping the 0 page requires an SELinux policy permission,
> mmap_zero. Without SELinux mapping the 0 page requires CAP_SYS_RAWIO.
> Note that CAP_SYS_RAWIO roughly translates to uid=0 since noone really
> does interesting things with capabilities.
>
[...]
> I believe (from reading mailing lists) if you install WINE on ubuntu it
> automatically disables these protections. Thus installing wine on
> ubuntu disables ALL hardening gains of the mmap_min_addr.
>
[...]
> So on a non-SELinux system users would end up with exactly what they
> have today. if you want to run WINE as a normal user you have to set
> mmap_min_addr = 0 and then you no longer need CAP_SYS_RAWIO. Not much
> else we can do if your distro down support fine grained permissions.
>
Why do we not add a personality flag for this? With that, at least you
could require a harmless setuid wrapper for wine that just set the
personality bits and dropped root.
That at least would allow the people not shipping SELinux by default,
(which, really, is everyone but us, afaik...) to at least avoid having
to whole-sale disable the mmap_min_addr protections, which seems unduly
harsh... (If they're doing this without consulting the user, then, wow,
that's just anti-social...)
Of course, I might be missing the plot entirely here.
(Or, as someone else pointed out, force people to run this crap in a
VM. ;-)
regards, Kyle
On Tuesday 21 July 2009, Kyle McMartin wrote:
>
> Why do we not add a personality flag for this? With that, at least you
> could require a harmless setuid wrapper for wine that just set the
> personality bits and dropped root.
I thought the MMAP_PAGE_ZERO personality bit was exactly what Brad
was using in his demonstration. We don't need to define a new bit,
just use the one that's there ;-).
Then again, setting personality flags does not require root permissions
normally, so it's not an extremely strong protection, unless you also
start requiring CAP_SYS_RAWIO for setting MMAP_PAGE_ZERO.
Arnd <><
> one option is to allow the page to be mapped, but only as
> non-executable... in DOS that memory isn't where code lives anyway...
Bad idea.
My exploit (and many other null ptr dereference exploits) still will
work with a non-executable NULL mapping. The exploit I released was
different from the one I did in 2007 in that in 2007 I abused a function
pointer in the structure that was being pointed to and located at NULL.
In this case, no function pointers were used at all in the structure
being pointed to. I turned a 'trojaned data' situation into an
arbitrary OR of 0x1 and then into arbitrary code execution.
For instance, if I targeted the 3rd byte in the mmap file_operation
fptr, that would have given me a target userland address of 0x10000.
If I targeted the 4th byte, it would have given me 0x1000000, neither of
which fall under mmap_min_addr protection
Furthermore, without an actual NX implementation enforcing the lack of
PROT_EXEC, the kernel will execute in the region just fine.
-Brad
On 07/20/2009 08:14 PM, Christopher Pardy wrote:
> On 07/20/2009 07:23 PM, Eric Paris wrote:
>> Brad Spengler recently pointed out that the SELinux decision on how to
>> handle mmap_min_addr in some ways weakens system security vs on a system
>> without SELinux (and in other ways can be stronger). There is a trade
>> off and a reason I did what I did but I would like ideas and discussion
>> on how to get the best of both worlds.
>>
>> With SELinux mapping the 0 page requires an SELinux policy permission,
>> mmap_zero. Without SELinux mapping the 0 page requires CAP_SYS_RAWIO.
>> Note that CAP_SYS_RAWIO roughly translates to uid=0 since noone really
>> does interesting things with capabilities.
>>
>> The main problem is WINE. I'm told that WINE needs to map the 0 page to
>> support 16bit applications. On distros without SELinux users must
>> disable the mmap_min_addr protections for the ENTIRE system if they want
>> to run WINE.
>>
>> http://wiki.winehq.org/PreloaderPageZeroProblem
>>
>> I believe (from reading mailing lists) if you install WINE on ubuntu it
>> automatically disables these protections. Thus installing wine on
>> ubuntu disables ALL hardening gains of the mmap_min_addr.
>>
>> On Fedora, with SELinux, we allow users to run WINE in a domain that has
>> the SELinux mmap_zero permission and thus other programs/domains, do not
>> have security weakened. Your daemons, like the web server, are still
>> unable to map the 0 page. This is different than distros without
>> SELinux, remember they have to disable protection globally.
>>
>> But logged in users (by default), under SELinux, are 'unconfined' and
>> can by their very nature run their program in a domain that allows
>> mmap_zero. Trying to 'confine' the 'unconfined' user with SELinux is an
>> open problem which we don't currently even reasonably attempt address on
>> a broad scale. It's like besieging the user in a gentle mist of water
>> hoping they won't try to escape.
>>
>> So in Fedora your web server is a harder entry point to exploit kernel
>> NULL pointer bugs, but you have no protections against a malicious user.
>> On Ubuntu if you install WINE your web server and your logged in users
>> have no hardening. If you do not install WINE non-root is hardened,
>> anything running as root is not (aka suid apps, aka pulseaudio).
>>
>> So I was thinking today, wondering how to get the best (or at least
>> better) of both worlds on an SELinux system. I was considering adding a
>> second mmap_min_addr_lsm which would typically be equal to
>> mmap_min_addr. The purpose would be to allow the sysadmin to
>> individually control DAC/LSM protections. The security checks would
>> turn (sort of) into
>>
>> if (addr < mmap_min_addr)
>> ret |= capable(CAP_SYS_RAWIO);
>> if (addr < mmap_min_addr_lsm)
>> ret |= [insert LSM check here]
>>
>> So on a non-SELinux system users would end up with exactly what they
>> have today. if you want to run WINE as a normal user you have to set
>> mmap_min_addr = 0 and then you no longer need CAP_SYS_RAWIO. Not much
>> else we can do if your distro down support fine grained permissions.
>>
>> On an SELinux system what this lets me do is default to a stricter
>> setup, one in which you have to have both CAP_SYS_RAWIO and the selinux
>> mmap_zero permission. You, out of the box, get protection for both your
>> malicious logged in user and your web server. Then if a user decides to
>> run WINE they would turn down mmap_min_addr. This would remove the
>> requirement that they are root, and leave the system vulnerable to a
>> malicious user, but would still allow SELinux to protect confined
>> domains and daemons.
>>
>> Does anyone see a better way to let users continue to be users while
>> protecting most people? Yes SELinux is stronger in some areas than
>> without confining the ability to map the 0 page, but as has be rightly
>> pointed out it's foolish an broken that SELinux can weaken any
>> protections.
>>
>> -Eric
>>
>>
>> --
>> This message was distributed to subscribers of the selinux mailing list.
>> If you no longer wish to subscribe, send mail to [email protected] with
>> the words "unsubscribe selinux" without quotes as the message.
>
> If I'm not mistaken whats happening here is that some old 16 bit windows libraries have static addresses rather than pc offset or dynamically calculated ones. I don't think linux apps have ever done this so...
>
> Beyond wine no other applications should use this.
>
> The best solution would be to add code to wine which performs address recalculations either or the fly or at load time. Alternatively you could tell people who want 16 bit support to run wine or windows in a VM.
> Or a boolean could be added to allow wine to support 16 bit applications which would allow it to do this, basically the same idea you had but in a way past selinux users might understand better then needing to set a system value. Make the default value off and tell users, you set this and your kernel may be compromised, try with it off first, run it in a VM and only if you absolutely have to should you allow this.
>
> Christopher Pardy
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to [email protected] with
> the words "unsubscribe selinux" without quotes as the message.
I kind of like the idea of removing any special handling of LSM so it works the same with SELinux enabled or disabled.
Secondly remove the default ability for wine to work with 16 bit apps. So 32 bit wine apps just work out of the box without having to drop security. Then either force wine users to turn off the protection to run their 16 bit apps or add a setuid application wine16 which is setuid and drops capabilities, so that you can run your 16 bit apps.
On Tue, 2009-07-21 at 13:45 +1000, James Morris wrote:
> I strongly believe that we need to maintain the principle, in SELinux and
> LSM generally, that the interface is restrictive, i.e. that it can only
> further restrict access. It should be impossible, from a design point of
> view at least, for any LSM module to authorize more privilege than
> standard DAC. This has always been a specific design goal of LSM. (The
> capability module is an exception, as it has a fixed security policy and
> implements legacy DAC behavior; there's no way to "fix" this).
>
> In this case, we're not dealing with a standard form of access control,
> where access to a userland object is being mediated. We're trying to
> mediate the ability of a subject to bypass a separate mechanism which aims
> to protect the kernel itself from attack via a more fundamental system
> flaw. The LSM module didn't create that vulnerability directly, but it
> must not allow the vulnerability to be more easily exploited.
>
> The security policy writer should have a guarantee that the worst mistake
> they can make is to mess up their own security model; if they can mess up
> the base DAC security with MAC policy, we break that guarantee. There's
> also an issue of user confidence in the LSM modules, in that they should
> not be any worse off security-wise if they enable an enhanced protection
> mechanism.
Agreed. That guarantee has been stated from the very beginning for
SELinux; we shouldn't move away from it. Are there other places where
having an LSM weakens security by default?
At least in this case, the guarantee was broke because it was desired to
provide a stronger default. Eric could have made the default be no
protection at all.
Looking at the thread for the original patch at
http://marc.info/?l=selinux&m=118056208425164&w=4
Steve suggested that the sysctl could be controlled in SELinux by
labeling it. I am guessing that a new class and permission was created
so that there could be finer-grained controls? But if 16 bit wine apps
are all that need this, then do we really need such fine control?
--
James Carter <[email protected]>
National Security Agency
On Tue, 21 Jul 2009, James Carter wrote:
> Agreed. That guarantee has been stated from the very beginning for
> SELinux; we shouldn't move away from it. Are there other places where
> having an LSM weakens security by default?
There's a similar form of hook in vm_enough_memory, but the SELinux module
calls the DAC capability check first, so it seems ok from a policy
writer's point of view (i.e. worst case is they revert to DAC).
- James
--
James Morris
<[email protected]>
A dumb question perhaps, but while addling my brain over the tty layer I
was wondering if for the specific case of jump through NULL (which seems
to be the most common but by no means only problem case that gets
exploited) is there any reason we can't set a default breakpoint for
executing 0 and fix that up as a trap in the kernel ?
Even user code that needs zero page mapped such as BIOS hackery doesn't
actually jump through zero often if ever, and would be a userspace not a
kernel space trap source so could be fixed up.
Just a random "I've been staring at code too long today" thought ?
Alan
On Mon, Jul 27, 2009 at 20:19, Alan Cox<[email protected]> wrote:
> A dumb question perhaps, but while addling my brain over the tty layer I
> was wondering if for the specific case of jump through NULL (which seems
> to be the most common but by no means only problem case that gets
> exploited) is there any reason we can't set a default breakpoint for
> executing 0 and fix that up as a trap in the kernel ?
>
> Even user code that needs zero page mapped such as BIOS hackery doesn't
> actually jump through zero often if ever, and would be a userspace not a
> kernel space trap source so could be fixed up.
>
> Just a random "I've been staring at code too long today" thought ?
Alternatively, since such emulation code is almost certainly not
performance sensitive, perhaps it's possible to go the kmemcheck-style
route? We could probably "allow" userspace mappings of pages below
mmap_min_addr for unprivileged processes by trapping and
single-stepping the appropriate memory access instructions.
Every time anything tries to access that memory it would trigger a
fault; if the code is in kernel space we BUG() and dump a nastygram to
dmesg. For anything else, we either temporarily map the page and
single-step or simply emulate the instruction. Sure, it might be slow
as hell... but the unprivileged use-cases seem to be few and
far-between.
Cheers,
Kyle Moffett
Alan Cox <[email protected]> writes:
> A dumb question perhaps, but while addling my brain over the tty layer I
> was wondering if for the specific case of jump through NULL (which seems
> to be the most common but by no means only problem case that gets
> exploited) is there any reason we can't set a default breakpoint for
You mean a hardware breakpoint? Hardware break points are a precious
scarce resource. The people who rely on them would be likely
unhappy if you take one way from them.
-Andi
--
[email protected] -- Speaking for myself only.
On Tue, 28 Jul 2009 11:21:29 +0200
Andi Kleen <[email protected]> wrote:
> Alan Cox <[email protected]> writes:
>
> > A dumb question perhaps, but while addling my brain over the tty layer I
> > was wondering if for the specific case of jump through NULL (which seems
> > to be the most common but by no means only problem case that gets
> > exploited) is there any reason we can't set a default breakpoint for
>
> You mean a hardware breakpoint? Hardware break points are a precious
> scarce resource. The people who rely on them would be likely
> unhappy if you take one way from them.
They are a tiny minority and could always turn such protection off.
On Tue, Jul 28, 2009 at 11:00:28AM +0100, Alan Cox wrote:
> On Tue, 28 Jul 2009 11:21:29 +0200
> Andi Kleen <[email protected]> wrote:
>
> > Alan Cox <[email protected]> writes:
> >
> > > A dumb question perhaps, but while addling my brain over the tty layer I
> > > was wondering if for the specific case of jump through NULL (which seems
> > > to be the most common but by no means only problem case that gets
> > > exploited) is there any reason we can't set a default breakpoint for
> >
> > You mean a hardware breakpoint? Hardware break points are a precious
> > scarce resource. The people who rely on them would be likely
> > unhappy if you take one way from them.
>
> They are a tiny minority and could always turn such protection off.
"I don't use it so I don't care"
... in addition it doesn't help anyways because the x86 hardware
breakpoints can only trap an upto 4-8 bytes area. So if you set that
to 0 then a reference to >8(%reg),%reg==0 wouldn't trap.
That's a pretty common case with
x->member
where offsetof(..,, member) >= 8 (or 4 on 32bit)
Was very likely even the case on the original exploit.
If you use all available break points (making all gdb users unhappy)
then you could still only cover 64 bytes on 64bit, 32 on 32bit.
-Andi
--
[email protected] -- Speaking for myself only.
> If you use all available break points (making all gdb users unhappy)
> then you could still only cover 64 bytes on 64bit, 32 on 32bit.
Might want to double-check that math I think ;)
-Brad
On Tue, Jul 28, 2009 at 09:35:47AM -0400, Brad Spengler wrote:
> > If you use all available break points (making all gdb users unhappy)
> > then you could still only cover 64 bytes on 64bit, 32 on 32bit.
>
> Might want to double-check that math I think ;)
Good catch. I was off by one bit. It's 32 / 16.
Doesn't change the result I would guess though.
-Andi
--
[email protected] -- Speaking for myself only.
On Tue, Jul 28, 2009 at 11:21:29AM +0200, Andi Kleen wrote:
> Alan Cox <[email protected]> writes:
>
> > A dumb question perhaps, but while addling my brain over the tty layer I
> > was wondering if for the specific case of jump through NULL (which seems
> > to be the most common but by no means only problem case that gets
> > exploited) is there any reason we can't set a default breakpoint for
>
> You mean a hardware breakpoint? Hardware break points are a precious
> scarce resource. The people who rely on them would be likely
> unhappy if you take one way from them.
Could the page table flags be used to mask this region? i.e. force
PROT_NONE (with the "desired" flags stored elsewhere) and in the segv
handler check if it is kernel or user space, and then fix-up the flags and
continue if it's userspace? (I really don't know the internals on this,
but it would need to restore PROT_NONE on task-switch or something...)
-Kees
--
Kees Cook
Ubuntu Security Team
> Could the page table flags be used to mask this region? i.e. force
> PROT_NONE (with the "desired" flags stored elsewhere) and in the segv
> handler check if it is kernel or user space, and then fix-up the flags and
> continue if it's userspace? (I really don't know the internals on this,
> but it would need to restore PROT_NONE on task-switch or something...)
That's racy with multiple threads.
-Andi
--
[email protected] -- Speaking for myself only.