[ros-dev] Policy question

[Marc Schütz]

> -------- Original-Nachricht --------
> Datum: Sun, 4 Jun 2006 14:30:35 -0700
> Von: Myria <myriachan at cox.net>
> An: ReactOS Development List <ros-dev at reactos.org>
> Betreff: Re: [ros-dev] Policy question
> 
> Uhh, it's called a disassembly and the x86 manuals.  Attempting to access 
> kernel memory through 0xC0000000 in the normal DS segment is no different
> to 
> an x86 than accessing kernel memory through another segment at 0x00000000
> in 
> a custom segment whose base is 0xC0000000.  Both are going to fail because
> the page table says those are kernel addresses.  Since the default CS and
> DS 
> already have the limit as FFFFFFFF, there isn't a risk from a different 
> segment having the same values.
> 

This is only true for accesses from user mode. Are you sure that at no point, esp. somewhere in the APIs concerning VDMs, such a segment descriptor could be used from within the kernel?

> The only risk becomes the syscall and interrupt handlers.  The first thing
> these do is load all the segment registers with proper values, before
> trying 
> to read from memory.  So these aren't an issue either.  (CS and SS were 
> already loaded by the CPU.)
> 
> It wasn't that the designers didn't think about security, it's that they 
> thought *too much* about security.  They saw a risk when there really
> wasn't 
> one.  They just never noticed because they didn't care - NTVDM is
> basically 
> unsupported now.
> 
> Several years ago, I ran into several DOS programs that failed to run
> under 
> NTVDM solely because they were creating selectors that wrapped the address
> space, so yes, a compatibility problem does exist.
> 
> ReactOS already allows NtCreateSection with SEC_IMAGE on an ELF file,
> which 
> is much more of an extra feature than deleting an unnecessary security 
> check.
> 
> Melissa
> 
> ----- Original Message ----- 
> From: "Alex Ionescu" <ionucu at videotron.ca>
> To: "ReactOS Development List" <ros-dev at reactos.org>
> Sent: Sunday, June 04, 2006 13:23
> Subject: Re: [ros-dev] Policy question
> 
> > Myria wrote:
> >> Should ReactOS copy unnecessary restrictions that Windows has?
> >
> > You're not an NT designer. Just because you find something "unnecessary"
> > doesn't mean it is. Have you emailed anyone at Microsoft to verify your
> > theory, before potentially creating a security hole?
> >
> >>>> The example I'm thinking of is NtSetLdtEntries.  In Windows NT (and
> >> currently ReactOS as well), this function will not let you create an
> LDT
> >> entry whose limit is above the user/kernel barrier.
> >> This restriction sounds
> >> like it was made with security in mind, but it doesn't affect security.
> >
> > Then I would venture to guess that the internationally recognized and
> > distinguished engineers, professors and developers originally assigned
> > with the NT project didn't think of security.
> >
> >> The
> >> processor's page table will already block access to kernel memory no 
> >> matter
> >> what selector you use.  After all, the default user CS and DS already 
> >> have a
> >> limit of FFFFFFFF.
> >>
> >> Should such a problem be fixed?
> >
> > We don't even know if it's a problem yet. As of now, it's an assumption.
> >
> >>>> Fireball said "no, unless some 3rd party app or driver depends on
> them" 
> >> when
> >> I asked about whether such restrictions should be copied.  Pretty much 
> >> the
> >> only thing using NtSetLdtEntries is NTVDM, and this restriction already
> >> causes some DOS programs to break that would otherwise work.  (Such 
> >> programs
> >> are usually setting selectors that wrap the address space.)
> >
> > The decision was made a long time ago not to export additional APIs or
> > provide extra functionality which would cause programs to work on
> > ReactOS but not Windows. This creates a dangerous slippery slope. Not
> > being compatible doesn't only mean "not having all the features", it
> > also means "having more features". Once ROS DLLs/programs/3rd-party
> > applications start depending on ReactOS, you break compatibility. You
> > also start breaking the DDK license.
> >
> > But even before getting to this line of thought, I ask again. Have you
> > verified this allegation?
> >
> >>>> Melissa
> >>
> > Best regards,
> > Alex Ionescu
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev at reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev 
> 
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
      Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer