"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
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?
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.
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
Why not use the Mac OSX like logon? Or like SkyOS.
On 12/16/05, Michael B. Trausch fd0man@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@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
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.
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@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
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@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@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
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@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
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
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Please take this thread to the forums or ros-general.
WD -- <Russell> argh <Russell> iterator shenanigans :/
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
-
David Hinz -
David Johnson -
Dennis - Guardian -
Ged Murphy -
Jasper van de Gronde -
Jeff Smith -
KJKHyperion -
Michael B. Trausch -
WaxDragon -
Wesley Parish