Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1217446 > unrolled thread
| Started by | Stas Sergeev <stsp@list.ru> |
|---|---|
| First post | 2015-09-02 11:40 +0200 |
| Last post | 2015-09-02 22:30 +0200 |
| Articles | 20 on this page of 40 — 8 participants |
Back to article view | Back to linux.kernel
stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 11:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Andy Lutomirski <luto@amacapital.net> - 2015-09-02 16:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Kees Cook <keescook@chromium.org> - 2015-09-02 17:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 19:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-02 19:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 20:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-02 22:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 22:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Andy Lutomirski <luto@amacapital.net> - 2015-09-02 23:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-02 23:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 23:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Andy Lutomirski <luto@amacapital.net> - 2015-09-02 23:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 23:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-03 14:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 14:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-03 17:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 18:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-03 21:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 23:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Chuck Ebbert <cebbert.lkml@gmail.com> - 2015-09-04 12:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-04 12:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-04 14:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-04 15:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-04 22:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-04 23:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-04 23:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Raymond Jennings <shentino@gmail.com> - 2015-09-05 00:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-05 01:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-04 00:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-03 19:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Andy Lutomirski <luto@amacapital.net> - 2015-09-03 19:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 19:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 19:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 19:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 14:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-03 14:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Kees Cook <keescook@chromium.org> - 2015-09-02 20:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-02 22:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Andy Lutomirski <luto@amacapital.net> - 2015-09-02 20:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-02 22:30 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-04 12:50 +0200 |
| Message-ID | <q4WJb-86i-13@gated-at.bofh.it> |
| In reply to | #1218802 |
04.09.2015 13:09, Chuck Ebbert пишет: > On Fri, 4 Sep 2015 00:28:04 +0300 > Stas Sergeev <stsp@list.ru> wrote: > >> 03.09.2015 21:51, Austin S Hemmelgarn пишет: >>> There are servers out there that have this enabled and _never_ use it >>> at all, >> Unless I am mistaken, servers usually use special flavour of the >> distro (different from desktop install), where of course this will >> be disabled _compile time_. > Many (most?) distros use just one kernel for everything, because it's > just too much work to have a separate flavor for servers. But for example menuconfig promotes CONFIG_PREEMPT_NONE for server and CONFIG_PREEMPT for desktop. Also perhaps server would need an lts version rather than latest. I wonder if RHEL Server offers the generic desktop-suited kernel with vm86() enabled? In any case, if there is some generic mechanism to selectively disable syscalls at run-time for server, then vm86() is of course a good candidate. I wonder how many other syscalls are currently run-time controlled? (those that are not marked as an "attack surface" and defaulted to Y; I suppose the "attack surface" is currently only vm86()) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-09-04 14:40 +0200 |
| Message-ID | <q4YrE-292-25@gated-at.bofh.it> |
| In reply to | #1218818 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-09-04 06:46, Stas Sergeev wrote: > 04.09.2015 13:09, Chuck Ebbert пишет: >> On Fri, 4 Sep 2015 00:28:04 +0300 >> Stas Sergeev <stsp@list.ru> wrote: >> >>> 03.09.2015 21:51, Austin S Hemmelgarn пишет: >>>> There are servers out there that have this enabled and _never_ use it >>>> at all, >>> Unless I am mistaken, servers usually use special flavour of the >>> distro (different from desktop install), where of course this will >>> be disabled _compile time_. >> Many (most?) distros use just one kernel for everything, because it's >> just too much work to have a separate flavor for servers. > But for example menuconfig promotes CONFIG_PREEMPT_NONE for server > and CONFIG_PREEMPT for desktop. Also perhaps server would need an > lts version rather than latest. > I wonder if RHEL Server offers the generic desktop-suited kernel > with vm86() enabled? > > In any case, if there is some generic mechanism to selectively > disable syscalls at run-time for server, then vm86() is of course > a good candidate. I wonder how many other syscalls are currently > run-time controlled? (those that are not marked as an "attack surface" > and defaulted to Y; I suppose the "attack surface" is currently only vm86()) > OK, I think I need to clarify something here. The attack surface of a given system refers to the number of different ways that someone could potentially attack that system. An individual syscall is not in itself an attack surface, but is part of the attack surface for the whole system. One of the core concepts of proactive security is to minimize the attack surface, because the fewer ways someone could possibly attack you, the less likely it is that they will succeed. I however, referred to vm86 as a potential attack vector, which refers one way in which someone could attempt to attack the system (be it through arbitrary code execution , privilege escalation, or some other type of exploit), note that something does not need to have a known exploit to be classified as a potential attack vector (most black hat's out there will keep quiet about discovered exploits until they can actually make use of them themselves). By their very definition, every single site that userspace can call into the kernel is a _potential_ attack vector, including vm86(). vm86() is one of the more attractive syscalls to attempt to use as an attack vector on 32-bit x86 systems because it's relatively unaudited, significantly modifies the execution state of the processor, and is available on a majority of 32-bit x85 systems in the wild. This does not mean that it is exploitable directly, just that it's a possible target for an exploit.
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-04 15:10 +0200 |
| Message-ID | <q4YUG-2WE-11@gated-at.bofh.it> |
| In reply to | #1218895 |
04.09.2015 15:34, Austin S Hemmelgarn пишет: > On 2015-09-04 06:46, Stas Sergeev wrote: >> 04.09.2015 13:09, Chuck Ebbert пишет: >>> On Fri, 4 Sep 2015 00:28:04 +0300 >>> Stas Sergeev <stsp@list.ru> wrote: >>> >>>> 03.09.2015 21:51, Austin S Hemmelgarn пишет: >>>>> There are servers out there that have this enabled and _never_ use it >>>>> at all, >>>> Unless I am mistaken, servers usually use special flavour of the >>>> distro (different from desktop install), where of course this will >>>> be disabled _compile time_. >>> Many (most?) distros use just one kernel for everything, because it's >>> just too much work to have a separate flavor for servers. >> But for example menuconfig promotes CONFIG_PREEMPT_NONE for server >> and CONFIG_PREEMPT for desktop. Also perhaps server would need an >> lts version rather than latest. >> I wonder if RHEL Server offers the generic desktop-suited kernel >> with vm86() enabled? >> >> In any case, if there is some generic mechanism to selectively >> disable syscalls at run-time for server, then vm86() is of course >> a good candidate. I wonder how many other syscalls are currently >> run-time controlled? (those that are not marked as an "attack surface" >> and defaulted to Y; I suppose the "attack surface" is currently only vm86()) >> > OK, I think I need to clarify something here. > > The attack surface of a given system refers to the number of different ways that someone could potentially attack that system. An individual syscall is not in itself an attack surface, but is part of > the attack surface for the whole system. One of the core concepts of proactive security is to minimize the attack surface, because the fewer ways someone could possibly attack you, the less likely it > is that they will succeed. > > I however, referred to vm86 as a potential attack vector, which refers one way in which someone could attempt to attack the system (be it through arbitrary code execution , privilege escalation, or > some other type of exploit), note that something does not need to have a known exploit to be classified as a potential attack vector (most black hat's out there will keep quiet about discovered > exploits until they can actually make use of them themselves). By their very definition, every single site that userspace can call into the kernel is a _potential_ attack vector, including vm86(). But they are not marked as such, while vm86() is. And they do not have a run-time disabling knob. So why is such a big difference? > vm86() is one of the more attractive syscalls to attempt to use as an attack vector on 32-bit x86 systems because it's relatively unaudited, This can be changed if it is at least stripped from the known bloat, for example. This could have been done _before_ taking any other actions on it, because the actions would then be entirely different. Maybe, if it is properly cleaned up, the action will change from disabling or introducing a knob to auditing it? > significantly modifies the execution state of the > processor, and is available on a majority of 32-bit x85 systems in the wild. This does not mean that it is exploitable directly, just that it's a possible target for an exploit. So you say it is more dangerous than other syscalls, and I can believe you, but this needs a proper justification. Someone have to write why exactly it is more dangerous, can it be fixed or not, etc. Like it was done for mark_screen_rdonly - I am not asking you how it can be exploited because I take your word that this code is a potential risk. But it can be removed. If there are other risky parts, they also have to be identified. I simply don't think the sufficient justification was spelled to consider it as more dangerous than all other syscalls (modulo mmap_min_addr - that one was identified). What I mean is that when you add some knob for the user to make his system more (or less) secure, you have to also supply him with the information on what exactly risk does he accept. Eg if he writes 0 to mmap_min_addr, he knows exactly what risk does he accept, and that risk is low, he knows. But if he enables vm86() via some magic sysctl, the only info he has, is a vague "attack surface" in Kconfig. Do you really think it is enough for the user to make a decision and accept the risk? I think it is just a threatening attempt which will force him to never enable that, because he knows exactly zero about the risk he is going to accept. So what I ask for, is just: 1. Strip the bloat that is _already_ identified as dangerous 2. See what remains and properly document the danger 3. If that is _still_ needed, add a knob and document exactly what risk the user have to accept. But likely it won't be needed at that point at all. Instead, people go right to 3, shifting all the problems to the user, without even giving him the needed hint. I don't believe this follows an existing kernel policy at all. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-09-04 22:00 +0200 |
| Message-ID | <q55js-3sI-9@gated-at.bofh.it> |
| In reply to | #1218914 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-09-04 09:06, Stas Sergeev wrote: > 04.09.2015 15:34, Austin S Hemmelgarn пишет: >> On 2015-09-04 06:46, Stas Sergeev wrote: >>> 04.09.2015 13:09, Chuck Ebbert пишет: >>>> On Fri, 4 Sep 2015 00:28:04 +0300 >>>> Stas Sergeev <stsp@list.ru> wrote: >>>> >>>>> 03.09.2015 21:51, Austin S Hemmelgarn пишет: >>>>>> There are servers out there that have this enabled and _never_ use it >>>>>> at all, >>>>> Unless I am mistaken, servers usually use special flavour of the >>>>> distro (different from desktop install), where of course this will >>>>> be disabled _compile time_. >>>> Many (most?) distros use just one kernel for everything, because it's >>>> just too much work to have a separate flavor for servers. >>> But for example menuconfig promotes CONFIG_PREEMPT_NONE for server >>> and CONFIG_PREEMPT for desktop. Also perhaps server would need an >>> lts version rather than latest. >>> I wonder if RHEL Server offers the generic desktop-suited kernel >>> with vm86() enabled? >>> >>> In any case, if there is some generic mechanism to selectively >>> disable syscalls at run-time for server, then vm86() is of course >>> a good candidate. I wonder how many other syscalls are currently >>> run-time controlled? (those that are not marked as an "attack surface" >>> and defaulted to Y; I suppose the "attack surface" is currently only vm86()) >>> >> OK, I think I need to clarify something here. >> >> The attack surface of a given system refers to the number of different ways that someone could potentially attack that system. An individual syscall is not in itself an attack surface, but is part of >> the attack surface for the whole system. One of the core concepts of proactive security is to minimize the attack surface, because the fewer ways someone could possibly attack you, the less likely it >> is that they will succeed. >> >> I however, referred to vm86 as a potential attack vector, which refers one way in which someone could attempt to attack the system (be it through arbitrary code execution , privilege escalation, or >> some other type of exploit), note that something does not need to have a known exploit to be classified as a potential attack vector (most black hat's out there will keep quiet about discovered >> exploits until they can actually make use of them themselves). By their very definition, every single site that userspace can call into the kernel is a _potential_ attack vector, including vm86(). > But they are not marked as such, while vm86() is. > And they do not have a run-time disabling knob. > So why is such a big difference? Take for example read(), this is not a very likely attack vector because: 1. It does exactly _one_ thing. 2. It only copies data to the calling process. 3. It has no odd interactions with mm. 4. The only modification it does to how the processor is executing is for the context switch to kernel mode and back to user mode. 5. It is _very_ well audited. Overall, this means that read() is a relatively low risk. fork() is slightly more attractive as an exploit target, because it doesn't fit points 2 and 4 above. vm86() is much more attractive because it doesn't fit any of the 5 points above. Other system calls that I know of that fit less than 3 of the 5 points above are: modify_ldt(), perf_event_open(), ptrace(), and bpf(). I regard all of these as potentially more attractive than vm86 because they are available on a wider range of platforms. modify_ldt, perf_event_open, and ptrace all have ways to disable or significantly secure them, and have also all had exploits at some point in time. bpf is able to be disabled, but has not yet had any publicly documented exploits that I know of, but this does not mean that it is secure (especially considering how new it is). > >> vm86() is one of the more attractive syscalls to attempt to use as an attack vector on 32-bit x86 systems because it's relatively unaudited, > This can be changed if it is at least stripped from the known > bloat, for example. This could have been done _before_ taking any > other actions on it, because the actions would then be entirely > different. Maybe, if it is properly cleaned up, the action will > change from disabling or introducing a knob to auditing it? If you clean it up, I'd be happy to throw every thing I can think of at it. Even if I don't manage to discover any exploits in that case, I would still advocate against having it availible by default because it's functionality that is used by an consistently decreasing percentage of users (yes, I know lots of people use dosemu, the number of people who use Linux is however going up faster than the number of people who use dosemu (no, I don't have numbers to back this up, but it is statistically very likely to be the case), and I know a number of people who used to use it (myself included) who are moving to dosbox because the performance difference is getting less significant as computers get faster). >> significantly modifies the execution state of the >> processor, and is available on a majority of 32-bit x85 systems in the wild. This does not mean that it is exploitable directly, just that it's a possible target for an exploit. > So you say it is more dangerous than other syscalls, and I can > believe you, but this needs a proper justification. Someone have > to write why exactly it is more dangerous, can it be fixed or not, > etc. Like it was done for mark_screen_rdonly - I am not asking you > how it can be exploited because I take your word that this code is > a potential risk. But it can be removed. If there are other risky > parts, they also have to be identified. I simply don't think the > sufficient justification was spelled to consider it as more dangerous > than all other syscalls (modulo mmap_min_addr - that one was identified). I've already stated _why_ it's more dangerous: 1. It interacts in odd ways with memory management. 2. It directly modifies the execution state of the processor. It is no more potentially dangerous than any other system call that fits either description, I'm not trying to single out vm86, that just happens to be the syscall we are discussing right now. Another syscall that is a perfect example of both 1 and 2 would be modify_ldt, which _does_ have known exploits that required a rewrite, and now has a knob to disable it because most people don't use it. On almost any other OS out there, anything that did either 1 or 2 wouldn't have been merged in the first place (this is not intended as a statement against Linux), and to be honest, if someone tried to merge vm86 into Linux today, they would have a very hard time convincing people it is worth it. Reiterating what I've said before, albeit paraphrased: 1. If you can call code, there is a possibility that you can exploit it. 2. Just because there are no publicly documented exploits for something does not mean that it is secure. 3. Having functionality enabled by default that you don't need is a Very Bad Thing, this is why Windows has historically had so many security issues. 4. Reactive security is utterly useless for any system that has already been exploited. If you have been hacked by someone who actually knows what they are doing, then even your hardware is suspect at that point, and patching the initial entry point will not provide any reasonable degree of safety. Also, this will be the last reply I make on this sub-thread, if this does not convince you of any of the points I've made, then nothing I can say is likely to.
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-04 23:20 +0200 |
| Message-ID | <q56yS-5q4-5@gated-at.bofh.it> |
| In reply to | #1219279 |
04.09.2015 22:51, Austin S Hemmelgarn пишет: > On 2015-09-04 09:06, Stas Sergeev wrote: >> 04.09.2015 15:34, Austin S Hemmelgarn пишет: >>> On 2015-09-04 06:46, Stas Sergeev wrote: >>>> 04.09.2015 13:09, Chuck Ebbert пишет: >>>>> On Fri, 4 Sep 2015 00:28:04 +0300 >>>>> Stas Sergeev <stsp@list.ru> wrote: >>>>> >>>>>> 03.09.2015 21:51, Austin S Hemmelgarn пишет: >>>>>>> There are servers out there that have this enabled and _never_ >>>>>>> use it >>>>>>> at all, >>>>>> Unless I am mistaken, servers usually use special flavour of the >>>>>> distro (different from desktop install), where of course this will >>>>>> be disabled _compile time_. >>>>> Many (most?) distros use just one kernel for everything, because it's >>>>> just too much work to have a separate flavor for servers. >>>> But for example menuconfig promotes CONFIG_PREEMPT_NONE for server >>>> and CONFIG_PREEMPT for desktop. Also perhaps server would need an >>>> lts version rather than latest. >>>> I wonder if RHEL Server offers the generic desktop-suited kernel >>>> with vm86() enabled? >>>> >>>> In any case, if there is some generic mechanism to selectively >>>> disable syscalls at run-time for server, then vm86() is of course >>>> a good candidate. I wonder how many other syscalls are currently >>>> run-time controlled? (those that are not marked as an "attack surface" >>>> and defaulted to Y; I suppose the "attack surface" is currently >>>> only vm86()) >>>> >>> OK, I think I need to clarify something here. >>> >>> The attack surface of a given system refers to the number of >>> different ways that someone could potentially attack that system. >>> An individual syscall is not in itself an attack surface, but is >>> part of >>> the attack surface for the whole system. One of the core concepts >>> of proactive security is to minimize the attack surface, because the >>> fewer ways someone could possibly attack you, the less likely it >>> is that they will succeed. >>> >>> I however, referred to vm86 as a potential attack vector, which >>> refers one way in which someone could attempt to attack the system >>> (be it through arbitrary code execution , privilege escalation, or >>> some other type of exploit), note that something does not need to >>> have a known exploit to be classified as a potential attack vector >>> (most black hat's out there will keep quiet about discovered >>> exploits until they can actually make use of them themselves). By >>> their very definition, every single site that userspace can call >>> into the kernel is a _potential_ attack vector, including vm86(). >> But they are not marked as such, while vm86() is. >> And they do not have a run-time disabling knob. >> So why is such a big difference? > Take for example read(), this is not a very likely attack vector because: > 1. It does exactly _one_ thing. > 2. It only copies data to the calling process. > 3. It has no odd interactions with mm. > 4. The only modification it does to how the processor is executing is > for the context switch to kernel mode and back to user mode. > 5. It is _very_ well audited. > Overall, this means that read() is a relatively low risk. > fork() is slightly more attractive as an exploit target, because it > doesn't fit points 2 and 4 above. > vm86() is much more attractive because it doesn't fit any of the 5 > points above. I agree. vm86() is a mess. My point is that its risky parts and useless funtionality is _already_ known (even I can point to the particular code parts than can simply be removed). As such, it simply had to be re-visited and cleaned up to match at least 1 and 3 (and then maybe 5). This wasn't done, and the knob was introduced _instead_ of doing this. I am not saying the knob should not exist. Actually the mmap_min_addr is exactly the knob I am asking for: well justified, well known. > Other system calls that I know of that fit less than 3 of the 5 points > above are: modify_ldt(), perf_event_open(), ptrace(), and bpf(). I > regard all of these as potentially more attractive than vm86 Agree! Are they marked as "attack surface" in the Kconfig or elsewhere? Or maybe their risk is properly documented? Or not documented at all? IMHO when security is concerned, documenting things properly is very important. >>> vm86() is one of the more attractive syscalls to attempt to use as >>> an attack vector on 32-bit x86 systems because it's relatively >>> unaudited, >> This can be changed if it is at least stripped from the known >> bloat, for example. This could have been done _before_ taking any >> other actions on it, because the actions would then be entirely >> different. Maybe, if it is properly cleaned up, the action will >> change from disabling or introducing a knob to auditing it? > If you clean it up, I'd be happy to throw every thing I can think of > at it. I'll look into doing that perhaps. At least I can try to test it after changes. > Even if I don't manage to discover any exploits in that case, I > would still advocate against having it availible by default because > it's functionality that is used by an consistently decreasing > percentage of users (yes, I know lots of people use dosemu, the number > of people who use Linux is however going up faster than the number of > people who use dosemu (no, I don't have numbers to back this up, but > it is statistically very likely to be the case), Yes, I won't challenge that expectation. dosemu supports legacy system, so its user base is doomed to decrease. I was only against the assumptions that it is below 1%. In fact, if we consider the users that run dosemu just once, type "dir" in the dos prompt, get some nostalgie and close it forever, I guess we'll get the surprisingly large numbers. :) > and I know a number of people who used to use it (myself included) who > are moving to dosbox because the performance difference is getting > less significant as computers get faster). dosemu is not only about performance, but also about a better HW support for which only the DOS drivers exist. Also I wonder how well dosbox scales and performes in a multicore setup. dosemu2 had a lot of manpower invested into a multicore scalability. As a result, you can play Need For Speed on an old dual-core notebook. >>> significantly modifies the execution state of the >>> processor, and is available on a majority of 32-bit x85 systems in >>> the wild. This does not mean that it is exploitable directly, just >>> that it's a possible target for an exploit. >> So you say it is more dangerous than other syscalls, and I can >> believe you, but this needs a proper justification. Someone have >> to write why exactly it is more dangerous, can it be fixed or not, >> etc. Like it was done for mark_screen_rdonly - I am not asking you >> how it can be exploited because I take your word that this code is >> a potential risk. But it can be removed. If there are other risky >> parts, they also have to be identified. I simply don't think the >> sufficient justification was spelled to consider it as more dangerous >> than all other syscalls (modulo mmap_min_addr - that one was >> identified). > I've already stated _why_ it's more dangerous: > 1. It interacts in odd ways with memory management. If you mean the mark_screen_rdonly hack, then it can just be removed. > 2. It directly modifies the execution state of the processor. Yes. > It is no more potentially dangerous than any other system call that > fits either description, I'm not trying to single out vm86, Not you, but in Kconfig it has the "attack surface" tag, which singles it out quite a lot. This alone is a big part of the problem. Well, for you it is just a minor detail, but for me - it is a direct threatening of my users. > that just happens to be the syscall we are discussing right now. > Another syscall that is a perfect example of both 1 and 2 would be > modify_ldt, which _does_ have known exploits that required a rewrite, So why not to rewrite (or actually just clean up) the vm86() syscall _before_ any exploit is found? Part of that was already done AFAIK, but there are still the things to strip. > and now has a knob to disable it because most people don't use it. Well, a very recent knob, I didn't know about it yet. But please, see the difference: 1. As you said, the code was first rewritten to stay in shape 2. There was no known security threats at the point of adding the knob, so there was a much softer wording in Kconfig (I admit it could have been even softer though). What we have in vm86() case: 1. It is full of risky code which no one rewrites (a lie, Brian Gerst does, but its still there) 2. The knob is added with an intention for it to always stay disabled; the heavy wording in Kconfig just confirms this and threatens the users. I am not against the knob as a whole, just against how it was done in this particular case. It have been done much better in case of modify_ldt(). > Reiterating what I've said before, albeit paraphrased: > 1. If you can call code, there is a possibility that you can exploit it. > 2. Just because there are no publicly documented exploits for > something does not mean that it is secure. > 3. Having functionality enabled by default that you don't need is a > Very Bad Thing, this is why Windows has historically had so many > security issues. > 4. Reactive security is utterly useless for any system that has > already been exploited. If you have been hacked by someone who > actually knows what they are doing, then even your hardware is suspect > at that point, and patching the initial entry point will not provide > any reasonable degree of safety. > > Also, this will be the last reply I make on this sub-thread, if this > does not convince you of any of the points I've made, then nothing I > can say is likely to Its not that I disagree with this your e-mail. I am actually agree with most. But we see the problem from different sides. I care about my users that will be presented with the strange knob, enabling which will allow them to run dosemu, but will "turn their OS into an attack surface". What will they choose? I care. But you care about your users, so you do not share my concerns. When the user is asked to accept some risk, IMHO he needs some description of this risk. And he needs to know that this risk was at least minimized as possible by the developers. If he knows the otherwise, he'll never accept the risk and never enable vm86(). This is what important to me, but you have different objectives, so for you this is just a minor detail. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-04 23:30 +0200 |
| Message-ID | <q56Iy-5B5-9@gated-at.bofh.it> |
| In reply to | #1219327 |
05.09.2015 00:16, Stas Sergeev пишет: > I agree. vm86() is a mess. > My point is that its risky parts and useless funtionality > is _already_ known (even I can point to the particular code > parts than can simply be removed). As such, it simply had > to be re-visited and cleaned up to match at least 1 and 3 > (and then maybe 5). This wasn't done, and the knob was > introduced _instead_ of doing this. Grr, I mean it was disabled by default instead of doing this, and the knob was only proposed, not added. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Raymond Jennings <shentino@gmail.com> |
|---|---|
| Date | 2015-09-05 00:50 +0200 |
| Message-ID | <q57XY-7hG-9@gated-at.bofh.it> |
| In reply to | #1219329 |
On 09/04/15 14:30, Stas Sergeev wrote: > 05.09.2015 00:16, Stas Sergeev пишет: >> I agree. vm86() is a mess. >> My point is that its risky parts and useless funtionality >> is _already_ known (even I can point to the particular code >> parts than can simply be removed). As such, it simply had >> to be re-visited and cleaned up to match at least 1 and 3 >> (and then maybe 5). This wasn't done, and the knob was >> introduced _instead_ of doing this. > Grr, I mean it was disabled by default instead of doing this, > and the knob was only proposed, not added. You can't just pull vm86 out of the kernel anyway. dosemu is a userspace application that depends on it, so pulling this feature out would be a big fat regression, period. I would personally rather not hear about how "it's a legacy program so its userbase is shrinking" used as any sort of excuse to ignore the fact that we shouldn't break userspace. I can even say as a user that vm86 is important to me. By all means, cleaning up vm86 is a good idea. But removing it or fencing it off with a strong deprecation doesn't sound like the right idea. > -- > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-05 01:20 +0200 |
| Message-ID | <q58r0-84H-1@gated-at.bofh.it> |
| In reply to | #1219354 |
05.09.2015 01:46, Raymond Jennings пишет: > On 09/04/15 14:30, Stas Sergeev wrote: >> 05.09.2015 00:16, Stas Sergeev пишет: >>> I agree. vm86() is a mess. >>> My point is that its risky parts and useless funtionality >>> is _already_ known (even I can point to the particular code >>> parts than can simply be removed). As such, it simply had >>> to be re-visited and cleaned up to match at least 1 and 3 >>> (and then maybe 5). This wasn't done, and the knob was >>> introduced _instead_ of doing this. >> Grr, I mean it was disabled by default instead of doing this, >> and the knob was only proposed, not added. > > You can't just pull vm86 out of the kernel anyway. dosemu is a > userspace application that depends on it, so pulling this feature out > would be a big fat regression, period. > > I would personally rather not hear about how "it's a legacy program so > its userbase is shrinking" used as any sort of excuse to ignore the > fact that we shouldn't break userspace. > > I can even say as a user that vm86 is important to me. > > By all means, cleaning up vm86 is a good idea. But removing it or > fencing it off with a strong deprecation doesn't sound like the right > idea. Yes, that's what I was saying lengthy. Fencing it off may help those who does not use it, and that's what most people here worry about. BUT it will also do a big harm to those who uses it, unless done properly like for modify_ldt(), or *sigh* just with mmap_min_addr. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-04 00:40 +0200 |
| Message-ID | <q4LkK-bw-9@gated-at.bofh.it> |
| In reply to | #1218519 |
03.09.2015 21:51, Austin S Hemmelgarn пишет: > As of right now, the only open-source project that I know of that is > actually actively used by people on new kernels that uses vm86 is > dosemu (and the forked dosemu2). the only other open source user of > vm86() that I know of is v86d, According to this: http://lrmi.cvs.sourceforge.net/viewvc/lrmi/lrmi/README?revision=1.2&view=markup we have to be careful with at least MPlayer, MPlayerXP and svgalib (svgalib was already mentioned). Maybe all of them already stopped using vm86(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-09-03 19:00 +0200 |
| Message-ID | <q4G1I-Xg-19@gated-at.bofh.it> |
| In reply to | #1218384 |
On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
>
> This lets you turn this on or off at runtime.
Tangential aside: we already effectively have a flag that could turn
off vm86 mode dynamically: /proc/sys/vm/mmap_min_addr.
Sadly (or not) we default it to 4096, which still leaves vm86 mode
usable, although it effectively disables *dos* use for it. Which is
kind of the worst of both worlds: you can use the vm86() system call
for bad things (if you can find a hole in it), but you probably cannot
actually use it for DOS emulation, because the traditional BIOS data
segment is at 0040.
Anyway, what that means is that pretty much the only *valid* use of
vm86() mode is probably when the system maintainer has set
'mmap_min_addr' to zero. So we could probably use that as an already
existing flag that disallows vm86 by our current default values.
Stas - can you confirm that to actually use vm86 mode, you end up
setting that mmap_min_addr thing to zero? Or do you end up using a
mixed-mode setup, where you use vm86() for most things, but emulate
things that trap in the zero page?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-09-03 19:30 +0200 |
| Message-ID | <q4GuJ-1LD-1@gated-at.bofh.it> |
| In reply to | #1218444 |
On Thu, Sep 3, 2015 at 10:19 AM, Stas Sergeev <stsp@list.ru> wrote: > 03.09.2015 19:57, Linus Torvalds пишет: >> On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn >> <ahferroin7@gmail.com> wrote: >>> >>> This lets you turn this on or off at runtime. >> >> Tangential aside: we already effectively have a flag that could turn >> off vm86 mode dynamically: /proc/sys/vm/mmap_min_addr. >> >> Sadly (or not) we default it to 4096, which still leaves vm86 mode >> usable, although it effectively disables *dos* use for it. Which is >> kind of the worst of both worlds: you can use the vm86() system call >> for bad things (if you can find a hole in it), but you probably cannot >> actually use it for DOS emulation, because the traditional BIOS data >> segment is at 0040. >> >> Anyway, what that means is that pretty much the only *valid* use of >> vm86() mode is probably when the system maintainer has set >> 'mmap_min_addr' to zero. So we could probably use that as an already >> existing flag that disallows vm86 by our current default values. >> >> Stas - can you confirm that to actually use vm86 mode, you end up >> setting that mmap_min_addr thing to zero? Or do you end up using a >> mixed-mode setup, where you use vm86() for most things, but emulate >> things that trap in the zero page? > Yes, good point. > dosemu complains about /proc/sys/vm/mmap_min_addr. > Trapping on zero-page access will likely not work, because > IIRC some distros raise that value even more. > So yes, please use that to completely disable vm86(). > You won't even break dosemu's checks, because it (obviously) > tries mmap() before trying vm86(). > I'm okay with that. Shall I send a patch? There's also vbetool, but I think that almost everyone considers it dead at this point, and it seems reasonably likely that it needs mmap_min_addr == 0 as well. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-03 19:40 +0200 |
| Message-ID | <q4GEq-1WX-25@gated-at.bofh.it> |
| In reply to | #1218453 |
03.09.2015 20:21, Andy Lutomirski пишет: > On Thu, Sep 3, 2015 at 10:19 AM, Stas Sergeev <stsp@list.ru> wrote: >> 03.09.2015 19:57, Linus Torvalds пишет: >>> On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn >>> <ahferroin7@gmail.com> wrote: >>>> >>>> This lets you turn this on or off at runtime. >>> >>> Tangential aside: we already effectively have a flag that could turn >>> off vm86 mode dynamically: /proc/sys/vm/mmap_min_addr. >>> >>> Sadly (or not) we default it to 4096, which still leaves vm86 mode >>> usable, although it effectively disables *dos* use for it. Which is >>> kind of the worst of both worlds: you can use the vm86() system call >>> for bad things (if you can find a hole in it), but you probably cannot >>> actually use it for DOS emulation, because the traditional BIOS data >>> segment is at 0040. >>> >>> Anyway, what that means is that pretty much the only *valid* use of >>> vm86() mode is probably when the system maintainer has set >>> 'mmap_min_addr' to zero. So we could probably use that as an already >>> existing flag that disallows vm86 by our current default values. >>> >>> Stas - can you confirm that to actually use vm86 mode, you end up >>> setting that mmap_min_addr thing to zero? Or do you end up using a >>> mixed-mode setup, where you use vm86() for most things, but emulate >>> things that trap in the zero page? >> Yes, good point. >> dosemu complains about /proc/sys/vm/mmap_min_addr. >> Trapping on zero-page access will likely not work, because >> IIRC some distros raise that value even more. >> So yes, please use that to completely disable vm86(). >> You won't even break dosemu's checks, because it (obviously) >> tries mmap() before trying vm86(). >> > > I'm okay with that. Shall I send a patch? I wonder if this patch will also stop calling it an attack surface. :) > There's also vbetool, but I think that almost everyone considers it > dead at this point, and it seems reasonably likely that it needs > mmap_min_addr == 0 as well. Most certainly, as vbios IIRC wants to read the addresses around 0x400, which it fills during POST. At least when dosemu used to map real vbios (long time ago), it also used to copy these values from /dev/mem, and they are within the first page. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-03 19:30 +0200 |
| Message-ID | <q4GuJ-1LD-3@gated-at.bofh.it> |
| In reply to | #1218444 |
03.09.2015 19:57, Linus Torvalds пишет: > On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn > <ahferroin7@gmail.com> wrote: >> >> This lets you turn this on or off at runtime. > > Tangential aside: we already effectively have a flag that could turn > off vm86 mode dynamically: /proc/sys/vm/mmap_min_addr. > > Sadly (or not) we default it to 4096, which still leaves vm86 mode > usable, although it effectively disables *dos* use for it. Which is > kind of the worst of both worlds: you can use the vm86() system call > for bad things (if you can find a hole in it), but you probably cannot > actually use it for DOS emulation, because the traditional BIOS data > segment is at 0040. > > Anyway, what that means is that pretty much the only *valid* use of > vm86() mode is probably when the system maintainer has set > 'mmap_min_addr' to zero. So we could probably use that as an already > existing flag that disallows vm86 by our current default values. > > Stas - can you confirm that to actually use vm86 mode, you end up > setting that mmap_min_addr thing to zero? Or do you end up using a > mixed-mode setup, where you use vm86() for most things, but emulate > things that trap in the zero page? Yes, good point. dosemu complains about /proc/sys/vm/mmap_min_addr. Trapping on zero-page access will likely not work, because IIRC some distros raise that value even more. So yes, please use that to completely disable vm86(). You won't even break dosemu's checks, because it (obviously) tries mmap() before trying vm86(). Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-03 19:20 +0200 |
| Message-ID | <q4Gl4-1yZ-15@gated-at.bofh.it> |
| In reply to | #1218384 |
03.09.2015 18:44, Austin S Hemmelgarn пишет:
> On 2015-09-03 08:15, Stas Sergeev wrote:
>> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>>> On 2015-09-02 17:53, Stas Sergeev wrote:
>>>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>>>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>>>>
>>>>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>>>>>> <luto@amacapital.net>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>>>>>> adding
>>>>>>>>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian,
>>>>>>>>>>>> what do you think?
>>>>>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>>>>>> enable it instead? While dosemu might still be in use, it isn't
>>>>>>>>>>> going
>>>>>>>>>>> to be the common case at all. So from a distro perspective, I
>>>>>>>>>>> think
>>>>>>>>>>> we'd probably rather have the default match the common case.
>>>>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>>>>>> match the ones of fedora?
>>>>>>>>> I didn't say that.
>>>>>>>> What you said was:
>>>>>>>> ---
>>>>>>>>
>>>>>>>> While dosemu might still be in use, it isn't going
>>>>>>>> to be the common case at all. So from a distro perspective
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ... which is likely true only in fedora circe.
>>>>>>>>
>>>>>>>>> The default right now is N.
>>>>>>>> In a not yet released kernel, unless I am mistaken.
>>>>>>>> If fedora already provides that kernel, other distros likely not.
>>>>>>>>
>>>>>>>>> I asked it be left
>>>>>>>>> that way. That's all.
>>>>>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>>>>>> Its easy to get back if its not too late.
>>>>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora
>>>>>>> could set it to N.
>>>>>> Sorry, I don't understand this sysctl proposal.
>>>>>> Could you please educate me what is it all about?
>>>>>> This sysctl will disable or enable the vm86() syscall at run-time,
>>>>>> right? What does it give us? If you disable something in the
>>>>>> config, this gives you, say, smaller kernel image. If OTOH you
>>>>>> add the run-time switch, it gives you a bigger image, regardless
>>>>>> of its default value.
>>>>>> I might be missing something, but I don't understand what
>>>>>> problem will this solve? Have I missed some earlier message
>>>>>> in this thread?
>>>>> For the 99%+ of users who don't use dosemu, it prevents exploits that
>>>>> target vm86 from attacking their kernel.
>>>> I don't think the attack scenario was satisfactory explained.
>>>> IIRC you only said that
>>>> ---
>>>>
>>>> The mark_screen_rdonly thing is still kind of scary. It changes PTEs
>>>> on arbitrary mappings behind the vm's back.
>>>>
>>>> ---
>>>> Just go ahead and remove mark_screen_rdonly, big deal.
>>>> Is this all of the threat?
>>>> Or do we treat _every_ syscall as the potential attack target?
>>> Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target
>> ... and should be removed.
>> Remove mark_screen_rdonly hack.
>>
>>> as is anything that messes with execution mode or privilege
>>> level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in). This does potentially all three (depending on how it's called). Just
>>> because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain
>>> root-equivalent privileges.
>> Please be specific, show the dangerous code, we'll then remove it
>> or fix it.
>>
> The problem is we don't _know_ what could be exploited in there. There is no way to know for certain without a full audit of the code (and even that wouldn't be certain to catch everything), which is
> almost certainly not going to happen unless someone pays a very large amount of money for it.
>
> We should not however, wait to disable something by default that (probably) less than 1% of the people who are running Linux on systems that can even use this are actually using until someone
> demonstrates a workable exploit. Security is not just a reactionary endeavor, you need to be proactive about it as well. This means minimizing the attack surface whenever possible (and yes, this an
> potential attack vector, regardless of whether there are known workable exploits or not).
>
> What has been proposed follows the existing convention on Linux (don't break userspace, and provide the option to people who actually care about their systems being secure to turn it off), the current
> proposal is to make it default to on in the defconfig, and have the sysctl default to leaving it enabled.
>
> On top of this, vm86 has a set of very specific niche use cases, most syscalls like this (AIO, bpf(), seccomp(), {m,f}advise(), etc) can only be turned on and off by completely rebuilding the kernel.
Please also note that none of the above are called an
"attack surface" in Kconfig.
Simply providing the new knob to disable looks harmless by
itself, but if you explicitly called something an "attack target",
unused, unmaintained etc and added a knob to disable it - this is
an entirely different story. It means you don't want to fix the
problems, but want to shift them to users, saying that they use it
on their own risk. This is what annoys me the most here.
If you claim this "follows the existing convention on Linux", then
please call all of the above syscalls an "attack target" in Kconfig
and add a knobs to them as well. Otherwise this doesn't follow any
convention at all. Adding a knob is an assertion that it _is_ dangerous.
It can't go as "oh, we just added a small knob, who cares". And the
fact that other rare syscalls do not have such knob, just confirms that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-03 14:10 +0200 |
| Message-ID | <q4Bv3-36H-11@gated-at.bofh.it> |
| In reply to | #1217859 |
03.09.2015 15:01, Austin S Hemmelgarn пишет: > On 2015-09-02 17:12, Stas Sergeev wrote: >> 02.09.2015 23:55, Andy Lutomirski пишет: >>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote: >>>> 02.09.2015 23:22, Josh Boyer пишет: >>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>>> 02.09.2015 20:46, Josh Boyer пишет: >>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski >>>>>>> <luto@amacapital.net> >>>>>>> wrote: >>>>>>>> I'd be amenable to switching the default back to y and perhaps >>>>>>>> adding >>>>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>>>>>>> what do you think? >>>>>>> Can you please leave the default as N, and have a sysctl option to >>>>>>> enable it instead? While dosemu might still be in use, it isn't >>>>>>> going >>>>>>> to be the common case at all. So from a distro perspective, I think >>>>>>> we'd probably rather have the default match the common case. >>>>>> The fact that fedora doesn't package dosemu, doesn't automatically >>>>>> mean all other distros do not too. Since when kernel defaults should >>>>>> match the ones of fedora? >>>>> I didn't say that. >>>> What you said was: >>>> --- >>>> >>>> While dosemu might still be in use, it isn't going >>>> to be the common case at all. So from a distro perspective >>>> >>>> --- >>>> ... which is likely true only in fedora circe. >>>> >>>>> The default right now is N. >>>> In a not yet released kernel, unless I am mistaken. >>>> If fedora already provides that kernel, other distros likely not. >>>> >>>>> I asked it be left >>>>> that way. That's all. >>>> Lets assume its not yet N, unless there was a kernel release already. >>>> Its easy to get back if its not too late. >>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora >>> could set it to N. >> Sorry, I don't understand this sysctl proposal. >> Could you please educate me what is it all about? >> This sysctl will disable or enable the vm86() syscall at run-time, >> right? What does it give us? If you disable something in the >> config, this gives you, say, smaller kernel image. If OTOH you >> add the run-time switch, it gives you a bigger image, regardless >> of its default value. >> I might be missing something, but I don't understand what >> problem will this solve? Have I missed some earlier message >> in this thread? > The problem this solves is not kernel size, that is not the only reason for wanting to disable a system call. In this case, it's a system call that is unused by all but a very few programs, which are > in turn used by a small percentage of users, and said system call does quite a few things that are potentially very dangerous. Disabling it reduces the attack surface of the system. Well, thanks for explaining the marketing part of the problem (initially I wasn't aware, but now Andy already spelled it too), but the reality is different. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-09-03 14:10 +0200 |
| Message-ID | <q4Bv3-36H-13@gated-at.bofh.it> |
| In reply to | #1217859 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-09-02 17:12, Stas Sergeev wrote: > 02.09.2015 23:55, Andy Lutomirski пишет: >> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote: >>> 02.09.2015 23:22, Josh Boyer пишет: >>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>> 02.09.2015 20:46, Josh Boyer пишет: >>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski >>>>>> <luto@amacapital.net> >>>>>> wrote: >>>>>>> I'd be amenable to switching the default back to y and perhaps >>>>>>> adding >>>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>>>>>> what do you think? >>>>>> Can you please leave the default as N, and have a sysctl option to >>>>>> enable it instead? While dosemu might still be in use, it isn't >>>>>> going >>>>>> to be the common case at all. So from a distro perspective, I think >>>>>> we'd probably rather have the default match the common case. >>>>> The fact that fedora doesn't package dosemu, doesn't automatically >>>>> mean all other distros do not too. Since when kernel defaults should >>>>> match the ones of fedora? >>>> I didn't say that. >>> What you said was: >>> --- >>> >>> While dosemu might still be in use, it isn't going >>> to be the common case at all. So from a distro perspective >>> >>> --- >>> ... which is likely true only in fedora circe. >>> >>>> The default right now is N. >>> In a not yet released kernel, unless I am mistaken. >>> If fedora already provides that kernel, other distros likely not. >>> >>>> I asked it be left >>>> that way. That's all. >>> Lets assume its not yet N, unless there was a kernel release already. >>> Its easy to get back if its not too late. >> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora >> could set it to N. > Sorry, I don't understand this sysctl proposal. > Could you please educate me what is it all about? > This sysctl will disable or enable the vm86() syscall at run-time, > right? What does it give us? If you disable something in the > config, this gives you, say, smaller kernel image. If OTOH you > add the run-time switch, it gives you a bigger image, regardless > of its default value. > I might be missing something, but I don't understand what > problem will this solve? Have I missed some earlier message > in this thread? The problem this solves is not kernel size, that is not the only reason for wanting to disable a system call. In this case, it's a system call that is unused by all but a very few programs, which are in turn used by a small percentage of users, and said system call does quite a few things that are potentially very dangerous. Disabling it reduces the attack surface of the system.
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2015-09-02 20:00 +0200 |
| Message-ID | <q4kuf-3Oz-33@gated-at.bofh.it> |
| In reply to | #1217776 |
On Wed, Sep 2, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: > On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote: >> I'd be amenable to switching the default back to y and perhaps adding >> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >> what do you think? > > Can you please leave the default as N, and have a sysctl option to > enable it instead? While dosemu might still be in use, it isn't going > to be the common case at all. So from a distro perspective, I think > we'd probably rather have the default match the common case. Linus will say the default must not break existing userspace... -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Josh Boyer <jwboyer@fedoraproject.org> |
|---|---|
| Date | 2015-09-02 22:30 +0200 |
| Message-ID | <q4mPo-7io-19@gated-at.bofh.it> |
| In reply to | #1217781 |
On Wed, Sep 2, 2015 at 1:52 PM, Kees Cook <keescook@chromium.org> wrote: > On Wed, Sep 2, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: >> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote: >>> I'd be amenable to switching the default back to y and perhaps adding >>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>> what do you think? >> >> Can you please leave the default as N, and have a sysctl option to >> enable it instead? While dosemu might still be in use, it isn't going >> to be the common case at all. So from a distro perspective, I think >> we'd probably rather have the default match the common case. > > Linus will say the default must not break existing userspace... Yeah, I guess. Which is weird when it's already N in his tree and we're talking about a config option that is explicitly there to disable things. Something will be broken if it's toggled, but oh well. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-09-02 20:20 +0200 |
| Message-ID | <q4kNA-4qF-27@gated-at.bofh.it> |
| In reply to | #1217776 |
On Wed, Sep 2, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: > On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote: >> I'd be amenable to switching the default back to y and perhaps adding >> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >> what do you think? > > Can you please leave the default as N, and have a sysctl option to > enable it instead? While dosemu might still be in use, it isn't going > to be the common case at all. So from a distro perspective, I think > we'd probably rather have the default match the common case. We can give a separate option that changes the default sysctl value at kernel config time. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Josh Boyer <jwboyer@fedoraproject.org> |
|---|---|
| Date | 2015-09-02 22:30 +0200 |
| Message-ID | <q4mPo-7io-21@gated-at.bofh.it> |
| In reply to | #1217792 |
On Wed, Sep 2, 2015 at 2:19 PM, Andy Lutomirski <luto@amacapital.net> wrote: > On Wed, Sep 2, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: >> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote: >>> I'd be amenable to switching the default back to y and perhaps adding >>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>> what do you think? >> >> Can you please leave the default as N, and have a sysctl option to >> enable it instead? While dosemu might still be in use, it isn't going >> to be the common case at all. So from a distro perspective, I think >> we'd probably rather have the default match the common case. > > We can give a separate option that changes the default sysctl value at > kernel config time. I'd certainly appreciate that. We've had terrible luck getting such options added to other things (like YAMA). josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web