From: Jeff D. <jd...@ad...> - 2004-11-29 20:35:09
|
Prompted by some questions from Blaisorblade about whether something like skas mode might be implemented on unpatched hosts, I went ahead and did exactly that. The basic idea is that in place of /proc/mm and PTRACE_FAULTINFO, we have a couple of extra pages in the userspace process to hold code that we are going to use to make it change its address space and to handle segfaults so addresses and access modes can be reported back to the kernel process. The end result is something that is very close to skas mode, just as secure, loses two pages of address space to UML rather than .5G, should be almost as fast, and runs on a stock host kernel. The patch is available as skas0 from my patches page - http://user-mode-linux.sourceforge.net/patches.html and there is a good deal of commentary associated with it. Jeff |
From: Blaisorblade <bla...@ya...> - 2004-11-30 16:07:17
|
On Monday 29 November 2004 22:26, William Stearns wrote: > Good afternoon, Jeff, > > On Mon, 29 Nov 2004, Jeff Dike wrote: > > Prompted by some questions from Blaisorblade about whether something like > > skas mode might be implemented on unpatched hosts, I went ahead and did > > exactly that. > > > > The basic idea is that in place of /proc/mm and PTRACE_FAULTINFO, we have > > a couple of extra pages in the userspace process to hold code that we are > > going to use to make it change its address space and to handle segfaults > > so addresses and access modes can be reported back to the kernel process. > > > > The end result is something that is very close to skas mode, just as > > secure, loses two pages of address space to UML rather than .5G, should > > be almost as fast, and runs on a stock host kernel. > > > > The patch is available as skas0 from my patches page - > > http://user-mode-linux.sourceforge.net/patches.html > > and there is a good deal of commentary associated with it. > > /me drops jaw.... :-) > > Nice work to both of you - I'm sincerely impressed. Jeff, is > there a place to grab a "all current 2.6 patches as a single patch" so I > can give it a try? Or do I need to grab all the 2.6 patches off the > sourceforge page and just apply them one at a time? Search "Auto-updating Jeff Dike tree" in uml-devel and take the script from Frank Sorenson in that thread, to download them less painfully - to apply them, you'd probably want to download and use quilt or patch-scripts. With patch-scripts (which I use locally) pushpatch 50 is the command which applies the next 50 patches (and the list of applied patches is saved, so you can easily go back and forth in the patch stack. I don't know the quilt syntax but it won't be totally different - it seems it is "quilt push 50". -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Gerd K. <kr...@by...> - 2004-11-30 17:40:13
|
Blaisorblade <bla...@ya...> writes: > I don't know the quilt syntax but it won't be totally different - it seems it > is "quilt push 50". Either "quilt push" (single patch), "quilt push -a" (all patches) or "quilt push <name>" (all up to and including patch "name"). It's a very nice tool, I've aliased it to "q" because I'm using it that often. Gerd -- #define printk(args...) fprintf(stderr, ## args) |
From: Blaisorblade <bla...@ya...> - 2004-11-30 18:59:13
|
On Tuesday 30 November 2004 19:16, Bodo Stroesser wrote: > Blaisorblade wrote: > > On Tuesday 30 November 2004 13:11, Bodo Stroesser wrote: > >>Jeff Dike wrote: > >>>Prompted by some questions from Blaisorblade about whether something > >>> like skas mode might be implemented on unpatched hosts, I went ahead > >>> and did exactly that. > >>>The basic idea is that in place of /proc/mm and PTRACE_FAULTINFO, we > >>> have a couple of extra pages in the userspace process to hold code that > >>> we are going to use to make it change its address space and to handle > >>> segfaults so addresses and access modes can be reported back to the > >>> kernel process. > >>>The end result is something that is very close to skas mode, just as > >>>secure, loses two pages of address space to UML rather than .5G, should > >>>be almost as fast, and runs on a stock host kernel. (From Bodo): > >>Looks like a very good idea! > >>But, please, be careful regarding security. If I understand the code > >> right, the stubs always are readable and executable, but not writable > >> for the user code. Thus, we have to ensure, that no one can singlestep a > >> syscall that resides there. > >>Unfortunatly, if IIRC, the generic kernel code doesn't > >>support more than one fixaddr range. > > Yes, I think. But why do you need it to be a fixaddr range? I guess you > > just need to mark it as reserved, right? The copy_from_user check, i.e. > > address_ok, can easily be fixed like we want. The cost is not relevant > > either, since a SKAS copy_from_user requires manually walking the page > > tables. > > > > But it's a different thing: you haven't got the requirement to map it at > > a fixed address in the kernel space, and it's the only purpose that only > > fixmap can accomplish. > > I agree. But no matter, which method is choosen, the relevant thing is to > make copy_from_user() work on this area. > > >>And it isn't possible to join the > >>stubs and vsyscall in a common area. So the obvious way to handle the > >> stubs with the same method as vsyscall won't work. > >>Since this is a security > >>issue, I decided not to CC the list. > > I hope that nobody is running that on production systems, I.e. "I hope" means that nobody should at all being running it on production, since it's a bad idea... > > so I hope it's > > a different case here. However, for now > For now, I agree. > But SKAS0 by design can be as safe as SKAS, so IMHO, we > should try do have the same security in both. Yes, that is *just* for now. I meant that this kind of security issue is different. In this case, publicising it, since we are speaking of beta-quality code, is a good idea. In fact, this time, I'm CC:ing the list. Publicising a vulnerability on production code, instead, is different, especially when it comes to posting exploits for testing. > >>By the way: Could you please shift the assembler-parts to sys-i386/XXX? > >>Bodo -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |