dealing with insecure-by-inattention Windows software

[Wesley Parish]

"insecure-by-inattention" - by that I mean software that must run as super-user
or otherwise (otherstupidly) it won't run at all.  ReactOS is not only intended
as a plug-in replacement for MS Windows, if I read this-and-that correctly, it's
also intended to "get it done right".  And so we can't have super-user as
default user, because that is Microsoft's thorn-in-the-flesh, and they can have
it.  I don't want it.

What I've been thinking is there is quite a bit of useful information and
knowledge being actively developed and used in the Unix/BSD/Linux field for
handling that sort of problem.  The BSD chroot jail is one such implementation -
there are even some aspects of the MS Windows directory structure that would
simplify the adaption of the chroot jail to the ReactOS.

[hardware]\Program Files\Abracadabra-Malware-Magnet\

"Abracadabra-Malware-Magnet" is a separate subdirectory within the Program
Files
directory.  Chroot jail, if I remember correctly, requires a separate directory
for each chrooted program so it sees itself as the one-and-only love of its
kernel's uptime.  The MS Windows directory structure already has this separable
directory structure.

What needs to be done is to ensure that it thinks it's the only one around.

There would be some sizeable problems - ensuring that the dlls would be
sufficiently robust to avoid being hijacked, is just one, ensuring that it
couldn't make any changes to dlls outside its directory is a bigger one, but
that could be handled by making sure it installed all its (uniquely) needed dlls
in its chroot jail.  Which a lot of Win32 programs do anyway.

What do people think?

Wesley Parish

"Sharpened hands are happy hands.
"Brim the tinfall with mirthful bands" 
- A Deepness in the Sky, Vernor Vinge

"I me.  Shape middled me.  I would come out into hot!" 
I from the spicy that day was overcasked mockingly - it's a symbol of the 
other horizon. - emacs : meta x dissociated-press

[KJKHyperion]

Wesley Parish wrote:

>  "insecure-by-inattention" - by that I mean
> software that must run as super-user or otherwise (otherstupidly) it won't run at
> all.
>  
read all you can find on the new security features in Windows Vista. The 
security model has been enhanced with various forms of Mandatory Access 
Control - among the many of them, the fact that all users (except 
System, i.e. services) are entirely powerless by default, even 
administrators, and a reauthentication is required every time privileges 
are needed (the user experience is pretty much identical to MacOSX) - 
and the application compatibility layer has been enhanced to the point 
it now fully implements a virtual filesystem view and a virtual registry 
view.

As for per-application sandboxing, it's very possible even today (with 
restricted tokens) and I use it daily. It has a couple of issues, one of 
which strictly technical and the others concerning usability. The 
technical issue is that sandboxes are barred from any form of 
client-side SSPI authentication - this means no accessing CIFS shares, 
no integrated authentication to an ISA proxy server, no remote 
administration through a snap-in, etc. (all attempts to create outbound 
credentials fail with a spurious "out of memory" error). It's hard to be 
worked around and presumably it's there for a reason other than "it was 
too hard to do".

The usability issues are many, many, many. Too many to be contained in a 
mailing list posting. I think it'd help to describe how an end user 
should interact with it, and then code whatever hacks are required for 
it, or rethink the interaction if the hacks prove to be too ugly.

The problem with your approach? too much maintenance. Even for a server. 
Setup packages for Windows tend to be a mistery, a surprise after 
another, a gift that keeps giving, can you really tell how to categorize 
their files and registry keys? and even then, are you sure that'd be a 
good idea?

[Jasper van de Gronde]

KJKHyperion wrote:
>   Wesley Parish wrote:
>  
> >   "insecure-by-inattention" - by that I
> > mean software that must run as 
> >  super-user or otherwise (otherstupidly) it won't run at all.
> >  
>  read all you can find on the new security features in Windows Vista. The 
>  security model has been enhanced with various forms of Mandatory Access 
>  Control - among the many of them, the fact that all users (except 
>  System, i.e. services) are entirely powerless by default, even 
>  administrators, and a reauthentication is required every time privileges 
>  are needed (the user experience is pretty much identical to MacOSX) - 
>  and the application compatibility layer has been enhanced to the point 
>  it now fully implements a virtual filesystem view and a virtual registry 
>  view. 
Are you saying that with Vista it's possible to give a program its own 
virtual view of the system which it can read and modify to its heart's 
content without affecting other programs? That would be simply divine.

[Michael B. Trausch]

On Fri, 2005-12-16 at 17:19 +0100, Jasper van de Gronde wrote:
>   
>  Are you saying that with Vista it's possible to give a program its own 
>  virtual view of the system which it can read and modify to its heart's 
>  content without affecting other programs? That would be simply divine.
>  
Yes, although IME, it doesn't work out so well, yet.

I just posted on that in this thread, as well.  There are more bad
things that happen as a result.

	- Mike

[David Johnson]

Why not use the Mac OSX like logon? Or like SkyOS.

On 12/16/05, Michael B. Trausch <fd0man(a)gmail.com> wrote:
>   On Fri, 2005-12-16 at 17:19 +0100, Jasper van de
> Gronde wrote:
> >  
> >  Are you saying that with Vista it's possible to give a program its own
> >  virtual view of the system which it can read and modify to its heart's
> >  content without affecting other programs? That would be simply divine.
> >  
>  Yes, although IME, it doesn't work out so well, yet.
>
>  I just posted on that in this thread, as well.  There are more bad
>  things that happen as a result.
>
>          - Mike
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  

--
David Johnson
http://www.davefilms.us
DaveFilms Digital Media - Audio [TM]
Producer , Writer,
Production Director/ Designer

[Jasper van de Gronde]

Michael B. Trausch wrote:
>   On Fri, 2005-12-16 at 17:19 +0100, Jasper van de
> Gronde wrote:
>  
> >  Are you saying that with Vista it's possible
> > to give a program its own 
> > virtual view of the system which it can read and modify to its heart's 
> > content without affecting other programs? That would be simply divine. 
>  
>  Yes, although IME, it doesn't work out so well, yet.
>  
>  I just posted on that in this thread, as well.  There are more bad
>  things that happen as a result. 
Apart from obvious problems with giving users enough rights to do common 
tasks, which isn't something I'm terribly worried about in my situation 
(I'm pretty much the only one who should be doing anything mildly 
advanced anyway), could you point out something that goes wrong? I'd 
assume that if an application has its own virtual view of the filesystem 
and registry (that it could read and potentially modify) that most 
applications would work reasonably well.

[Jeff Smith]

Wesley Parish wrote:
>   "insecure-by-inattention" - by that I mean
> software that must run as super-user
>  or otherwise (otherstupidly) it won't run at all.  ReactOS is not only intended
>  as a plug-in replacement for MS Windows, if I read this-and-that correctly, it's
>  also intended to "get it done right".  And so we can't have super-user as
>  default user, because that is Microsoft's thorn-in-the-flesh, and they can have
>  it.  I don't want it.
>
>  What I've been thinking is there is quite a bit of useful information and
>  knowledge being actively developed and used in the Unix/BSD/Linux field for
>  handling that sort of problem.  The BSD chroot jail is one such implementation -
>  there are even some aspects of the MS Windows directory structure that would
>  simplify the adaption of the chroot jail to the ReactOS.
>
>  [hardware]\Program Files\Abracadabra-Malware-Magnet\
>
>  "Abracadabra-Malware-Magnet" is a separate subdirectory within the Program
> Files
>  directory.  Chroot jail, if I remember correctly, requires a separate directory
>  for each chrooted program so it sees itself as the one-and-only love of its
>  kernel's uptime.  The MS Windows directory structure already has this separable
>  directory structure.
>
>  What needs to be done is to ensure that it thinks it's the only one around.
>
>  There would be some sizeable problems - ensuring that the dlls would be
>  sufficiently robust to avoid being hijacked, is just one, ensuring that it
>  couldn't make any changes to dlls outside its directory is a bigger one, but
>  that could be handled by making sure it installed all its (uniquely) needed dlls
>  in its chroot jail.  Which a lot of Win32 programs do anyway.
>
>  What do people think?
>
>  Wesley Parish
>
>  "Sharpened hands are happy hands.
>  "Brim the tinfall with mirthful bands" 
>  - A Deepness in the Sky, Vernor Vinge
>
>  "I me.  Shape middled me.  I would come out into hot!" 
>  I from the spicy that day was overcasked mockingly - it's a symbol of the 
>  other horizon. - emacs : meta x dissociated-press
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>     
Sorry but I'm not familiar wit chroot, so I didn't catch all of that but

why not have something where during the setup it'll ask you for the 
"system password" those would be used for the Administrator account 
first time logging in a window would appear, explaining the pro's and 
con's of the admin account and asks the user if he/she wants to create 
another account for his/her activities.

this approach will do 2 things 1. secure the computer because ReactOS 
would automatically prompt the user about the security of the admin 
account and 2. educate the user with a little bit about how the computer 
works.

"Every thing should be made as simple as possible, but not simpler." - 
Albert Einstein

[Dennis - Guardian]

Jeff Smith wrote:
>   Wesley Parish wrote:
> >   "insecure-by-inattention" - by that I
> > mean software that must run as 
> >  super-user
> >  or otherwise (otherstupidly) it won't run at all.  ReactOS is not 
> >  only intended
> >  as a plug-in replacement for MS Windows, if I read this-and-that 
> >  correctly, it's
> >  also intended to "get it done right".  And so we can't have 
> >  super-user as
> >  default user, because that is Microsoft's thorn-in-the-flesh, and 
> >  they can have
> >  it.  I don't want it.
> >
> >  What I've been thinking is there is quite a bit of useful information 
> >  and
> >  knowledge being actively developed and used in the Unix/BSD/Linux 
> >  field for
> >  handling that sort of problem.  The BSD chroot jail is one such 
> >  implementation -
> >  there are even some aspects of the MS Windows directory structure 
> >  that would
> >  simplify the adaption of the chroot jail to the ReactOS.
> >
> >  [hardware]\Program Files\Abracadabra-Malware-Magnet\
> >
> >  "Abracadabra-Malware-Magnet" is a separate subdirectory within the 
> >  Program Files
> >  directory.  Chroot jail, if I remember correctly, requires a separate 
> >  directory
> >  for each chrooted program so it sees itself as the one-and-only love 
> >  of its
> >  kernel's uptime.  The MS Windows directory structure already has this 
> >  separable
> >  directory structure.
> >
> >  What needs to be done is to ensure that it thinks it's the only one 
> >  around.
> >
> >  There would be some sizeable problems - ensuring that the dlls would be
> >  sufficiently robust to avoid being hijacked, is just one, ensuring 
> >  that it
> >  couldn't make any changes to dlls outside its directory is a bigger 
> >  one, but
> >  that could be handled by making sure it installed all its (uniquely) 
> >  needed dlls
> >  in its chroot jail.  Which a lot of Win32 programs do anyway.
> >
> >  What do people think?
> >
> >  Wesley Parish
> >
> >  "Sharpened hands are happy hands.
> >  "Brim the tinfall with mirthful bands" - A Deepness in the Sky, 
> >  Vernor Vinge
> >
> >  "I me.  Shape middled me.  I would come out into hot!" I from the 
> >  spicy that day was overcasked mockingly - it's a symbol of the other 
> >  horizon. - emacs : meta x dissociated-press
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >     
>  Sorry but I'm not familiar wit chroot, so I didn't catch all of that 
>  but why not have something where during the setup it'll ask you for 
>  the "system password" those would be used for the Administrator 
>  account first time logging in a window would appear, explaining the 
>  pro's and con's of the admin account and asks the user if he/she wants 
>  to create another account for his/her activities.
>
>  this approach will do 2 things 1. secure the computer because ReactOS 
>  would automatically prompt the user about the security of the admin 
>  account and 2. educate the user with a little bit about how the 
>  computer works.
>
>  "Every thing should be made as simple as possible, but not simpler." - 
>  Albert Einstein
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
since I do software development and
a little support for a living I 
think I'm qualified to make this comment.  As much as we'd like to 
educate people in this manner (no matter what software we write) most 
users will not read it and if they do, they will not understand it.
as much as choice is nice (and the open source way), it's probably 
better to just have them use the secure way by default.  make it easy to 
find and change the behavior for those that want to, but keep it out of 
the way of the average user.  maybe something like an option in the 
beginning of setup for 'let me choose everything' or 'just make it work' 
and an easy switch between advanced mode/just work mode somewhere else 
would be a good way to go?

Dennis

[David Hinz]

Maybe we should do it the unix/linux way, there is a root user, called 
administrator, he is allowed to do everything, but by default you 
shouldn't be able to login as administrator (the way it is on ubuntu and 
some other linux-distributions).
In addition to that, there could be another user, who is a more 
privileged user, but you can only login as him in setup mode. This is an 
option I would add to freeldr, it would boot ReactOS as usual, but 
deactivate alot of things like the network subsystem, most of the 
services, all autostarted applications and maybe some other things, so 
that the pc is more safe and is easier to repair, if something is broken 
or there  security holes, which can only be closed, if nearly everything 
is shutdown. After the user logged on with the password of the more 
privileged user, a window would popup and ask him, which of the shutdown 
things he wants to start, maybe he needs a network connection, who 
knows... but this concept is another topic.

Back to the ordinary user. He is limited, like an ordinary unix user. If 
he wants to acces something, he isn't allowed to do (like using the ms 
installer, or packetmanager, or changing specified registry values like 
autostart entries) a little window will popup and ask him for the system 
maintenance password (the password of the more privileged user).

And here is the difference between the administrator and the more 
privileged user: The administrator password can only be used in setup 
mode, when the user logged on as the more privileged user, the password 
of the more privileged user (who for example isn't allowed to format 
partitions) is the only password an ordinary user can use to gain some 
more privileges, he is only able to change very dangerous settings, if 
he booted in ReactOS setup mode, knows the system maintenance password 
and the administrator password.

With this method, it is nearly impossible to cause problems, the user 
didn't want to cause, as he really has to know, what he is doing to 
cause such things. No stupid virus will ever be able to cause really big 
damage and the best thing, this is more or less userfriendly.
Maybe additionally we could create different system maintenance 
passwords for every user or deny giving him the privilege of entering 
system maintenance mode, but that's something we shouldn't discuss at 
this moment.

Just my ideas on this topic...

Greets,

David Hinz

Dennis - Guardian schrieb:
>   Jeff Smith wrote:
> >   Sorry but I'm not familiar wit chroot, so I
> > didn't catch all of that 
> >  but why not have something where during the setup it'll ask you for 
> >  the "system password" those would be used for the Administrator 
> >  account first time logging in a window would appear, explaining the 
> >  pro's and con's of the admin account and asks the user if he/she wants 
> >  to create another account for his/her activities.
> >
> >  this approach will do 2 things 1. secure the computer because ReactOS 
> >  would automatically prompt the user about the security of the admin 
> >  account and 2. educate the user with a little bit about how the 
> >  computer works.
> >
> >  "Every thing should be made as simple as possible, but not simpler." - 
> >  Albert Einstein
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  since I do software development
> and a little support for a living I 
>  think I'm qualified to make this comment.  As much as we'd like to 
>  educate people in this manner (no matter what software we write) most 
>  users will not read it and if they do, they will not understand it.
>  as much as choice is nice (and the open source way), it's probably 
>  better to just have them use the secure way by default.  make it easy to 
>  find and change the behavior for those that want to, but keep it out of 
>  the way of the average user.  maybe something like an option in the 
>  beginning of setup for 'let me choose everything' or 'just make it work'
>
>  and an easy switch between advanced mode/just work mode somewhere else 
>  would be a good way to go?
>  
>  Dennis

[Michael B. Trausch]

On Fri, 2005-12-16 at 18:27 +0100, David Hinz wrote:
>   Maybe we should do it the unix/linux way, there is a
> root user, called 
>  administrator, he is allowed to do everything, but by default you 
>  shouldn't be able to login as administrator (the way it is on ubuntu and 
>  some other linux-distributions). 
[snip]

Windows Vista starts to put in a framework for something like this,
whereby if the user doesn't have admin privilege on the workstation,
they receive "virtualized" copies of the system folders.  It is sort of
like the BSD chroot jail, but you can't alter system-wide attributes.

Also, "Administrator" is the only account that can do a lot of things.
Even other designated computer administrators cannot do some of the
things that the Administrator can do, such as burn CDs, without help
from another set of privileges.  In using the system, it's Windows, for
sure, but it doesn't work the way you would expect Windows to work, and
it breaks a good bit of software.

Now, mind, Windows Vista isn't released yet, so they're going to be
working on addressing some of those issues (so they claim), but it's a
pain in the behind.  I couldn't figure out, for example, how to grant
special privileges to the other computer administrators, such as the
ability to use some of the control panels (Device Manager within System,
being one of them).  You could view the list as another computer admin,
but you couldn't install drivers or any of the like without logging into
the administrator account.  I found that pretty annoying, since I could
not find a way to grant that ability to another computer administrator.

Be careful, many applications make assumptions about how the security
mechanisms work, and if they do not work in the way that is expected,
they unexpectedly bail.  That is also kind of annoying.  Only a small
handful of applications can detect that scenerio and warn the user (such
as Nero).

Just a heads up.  :)

	Later,
	Mike

[David Hinz]

Well, I thought of doing it this way:

If an application requests something, an ordinary user isn't allowed to 
do without an system maintenance password, it pauses the thread, which 
asked, and pops up a window, asking for the system maintenance password 
(either the user specific, if he has one, or the systemwide password).

If the user enters a correct password, the system unpauses the thread 
and gives him, what it asked for, if not the user will be asked again 
some times (with the ability to abort) and after some tries, or if the 
user aborted, it unpauses the thread and rejects the requested action, 
so there shouldn't be that many compatibility issues, as the 
applications don't know, the action they requested is checked.

The only problem is, like you mentioned, if an application doesn't know, 
how to handle these rejected requests.
Maybe we can create a compatibility tool for it, so that we can start 
applications with system maintenance rights.

But something about burning: Why do we have to handle this like MS does?
We can enable burning for ordinary users by default, so this problem 
wouldn't appear...

Greets,

David Hinz

Michael B. Trausch schrieb:
>   On Fri, 2005-12-16 at 18:27 +0100, David Hinz wrote:
> >   Maybe we should do it the unix/linux way, there
> > is a root user, called 
> >  administrator, he is allowed to do everything, but by default you 
> >  shouldn't be able to login as administrator (the way it is on ubuntu and 
> >  some other linux-distributions). 
>  [snip]
>  
>  Windows Vista starts to put in a framework for something like this,
>  whereby if the user doesn't have admin privilege on the workstation,
>  they receive "virtualized" copies of the system folders.  It is sort of
>  like the BSD chroot jail, but you can't alter system-wide attributes.
>  
>  Also, "Administrator" is the only account that can do a lot of things.
>  Even other designated computer administrators cannot do some of the
>  things that the Administrator can do, such as burn CDs, without help
>  from another set of privileges.  In using the system, it's Windows, for
>  sure, but it doesn't work the way you would expect Windows to work, and
>  it breaks a good bit of software.
>  
>  Now, mind, Windows Vista isn't released yet, so they're going to be
>  working on addressing some of those issues (so they claim), but it's a
>  pain in the behind.  I couldn't figure out, for example, how to grant
>  special privileges to the other computer administrators, such as the
>  ability to use some of the control panels (Device Manager within System,
>  being one of them).  You could view the list as another computer admin,
>  but you couldn't install drivers or any of the like without logging into
>  the administrator account.  I found that pretty annoying, since I could
>  not find a way to grant that ability to another computer administrator.
>  
>  Be careful, many applications make assumptions about how the security
>  mechanisms work, and if they do not work in the way that is expected,
>  they unexpectedly bail.  That is also kind of annoying.  Only a small
>  handful of applications can detect that scenerio and warn the user (such
>  as Nero).
>  
>  Just a heads up.  :)
>  
>  	Later,
>  	Mike
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[WaxDragon]

Please take this thread to the forums or ros-general.

WD
--
<Russell> argh
<Russell> iterator shenanigans :/

[Ged Murphy]

WaxDragon wrote:
>   Please take this thread to the forums or ros-general.
Not just this thread, but all of these types of thread.
This is the development list, aimed at development issues in ReactOS.
At the moment, every other mail seems to be off topic.

Ged.

[David Hinz]

This is true, but the problem is in my oppinion these threads aren't 
general enough for the ros-general list, and many of these offtopic 
threads need oppinions of devs.

Maybe we need another list, maybe ros-tech or something like that.

Greets,

David Hinz

Ged Murphy schrieb:
>   WaxDragon wrote:
> >   Please take this thread to the forums or
> > ros-general. 
>  
>  Not just this thread, but all of these types of thread.
>  This is the development list, aimed at development issues in ReactOS.
>  At the moment, every other mail seems to be off topic.
>  
>  Ged.
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Michael B. Trausch]

On Fri, 2005-12-16 at 20:57 +0100, David Hinz wrote:
[snip]
>   
>  But something about burning: Why do we have to handle this like MS does?
>  We can enable burning for ordinary users by default, so this problem 
>  wouldn't appear...
>   
The rest of it sounds good... but the only problem with burning is that
it requires, as far as I understand, low-level driver access.... which
is something that could be considered an administrative privilege.  It's
sort of akin to what was found when people would run older DOS programs
that expected raw hardware access, under Windows NT.  They'd fail in
unpredictable ways because the operating system went and circumvented
the action, because raw hardware access could potentially change the
state of the system in a fashion that Windows NT wouldn't be aware of.
So it's prohibited.

Now, I don't know the low level logistics of burning a CD under Win32 as
of yet, but I was planning on looking around to see if I could find that
out - just for curiosity sake.  The theory that I have at the moment,
which seems to make sense to me, is that you bypass many layers of the
operating system to get around problems such as caching and what-not,
and use the low level I/O driver to do most of the work.  Probably even
bypassing the CD-ROM driver that Windows uses by default.  Now, I cannot
verify that theory under Vista, and didn't let Vista stay on my system
long enough to, because even on this system (a 1.8 GHz Duron w/ 512MB of
RAM) it was slow and felt very bulky.  Nero, even as an admin, crashed
quite a bit, and the burn-to-CD functionality of Windows seemed to not
work (they may have removed it, but I'm not sure).

In any case, I'm not sure if its very feasible to have a monitor look
for low-level requests and audit them saying "x requests are permitted
and the rest aren't" - but I'm not sure.  That could probably be
something akin to a network firewall, but only for internal system I/O.

	- Mike