Security of WINE and ReactOS: was Documents and settings
Hello Alex, I am going to drag this semi-off topic for a bit while I plant some ideas in people heads. --- Aleksey Bragin <aleksey(a)studiocerebral.com> wrote:
If ROS will support (and I bet it will!) NT 4.0 security model (or, better, Win2k then) it would be just great! Certainly people with deeper knowledge of this security model + knowledge of unix and also linux implementation model can specify the differences, and what's missing in them.
Note I only know a little about the Local Securty Authority but I think its not going to be to hard to implement if Wine and ReactOS work together on it. /me just doubts how much he can write. The unix security design of users and groups with permissions is not bad its just outdated. The nice thing about Unix is adding new security modules via PAM is not to bad except they are only for authentication. The unix concept of groups, users and permissions needs to be moved forward about 20 years. The SELinux stuff has really helped alot in this regard. (Please dont flame its the truth) I recently addressed this in a discussion about ReactOS. Currently our lsass does not exist. I think we have what we have parts of the security reference monitor already implemented in ntoskrnl and most of the parts are there for winlogon and the SAM database so we need to develop the lsass services and build out the authentaticaion modules for MSV1_0 auth. One of the nice things about the design of the Windows security module is that we can make plugins at both ends so that users can be granted access either based on a "domain" concept in winlogin/Gina using plugins for LDAP and PAM or via the lsass so users can be authencated locally. It would be nice if we could work with the Winehq people on this as I think we can share the parts of the security subsystem that reside in lsass. Think of it like this (Kernel support) wineserver/ntosknrl need to both implement the security refernce montior for privlaged use of the local system resources. I dont know how much of this wineserver really needs to take in to account in the initial incarnation. (Local security subsystem) Lsass works interactivly with services and the login system and can accept all sorts of nice plugins so we are not limited to just the standard Windows authentication. As a matter of fact you could replace large parts of they authentication system if you are supper paronoid. Think of lsass as the sentry for Windows. It talks to the SRM to make sure you are not doing anything you shouldnt be. (User interaction) Interaction with the user will come from Winlogon on ReactOS or on Unix the user should already be authenticated via Linux security. This can of course be done via the authentication modules described above. Once the user I wish I could attach the nice chart from Inside Windows NT so you could see the security subsystem. Its quite a piece of work and is quite a shame Windows security gets a bad name due to slack administrators. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html
Just my humble opinion on this: 1. One reason Unix security model is still around is that it is simple. ACLs and such need more administration and are more likely to be configured wrong. Unix, on the other hand, is compulsory (you *have* to set the permissions everywhere) and simple. In modern kernels (I use 2.6) you can also have more detailed permissions (ACLs, capabilities etc.) but they don't seem to be popular.. 2. Wine now runs in userspace, needing no privileges to operate. That's great because it protects itself both from bas win32 apps and bugs Wine may have. If it needed to obtain more system power, it would have to be in rootland. I wouldn't feel comfortable knowing that a win32 app runs on my system with some kind of root privileges. 3. There is a certain tradeoff between letting those permission-hungry apps (I recently came across an app that wanted to form its own ICMP packets) and being secure. IMHO restricting userspace apps is one reason Unix is secure (eg. no programmer will try to write an app that stores its data at '/' catalog, win apps may require write to 'C:\' or 'C:\windows\'). I prefer being secure.
Hello Alex,
I am going to drag this semi-off topic for a bit while I plant some ideas in people heads.
... Note I only know a little about the Local Securty Authority but I think its not going to be to hard to implement if Wine and ReactOS work together on it. /me just doubts how much he can write.
The unix security design of users and groups with permissions is not bad its just outdated. The nice thing about Unix is adding new security modules via PAM is not to bad except they are only for authentication. The unix concept of groups, users and permissions needs to be moved forward about 20 years. The SELinux stuff has really helped alot in this regard. (Please dont flame its the truth)
...
P. Christeas wrote:
Just my humble opinion on this: 1. One reason Unix security model is still around is that it is simple. ACLs and such need more administration and are more likely to be configured wrong.
That is absolutely true. Plus it is much easier to see who has what permissions in the Unix model. It gets even worse with ACLs when you have SMB share permissions as well. You can't tell very easily what the effective permissions are for each user.
Unix, on the other hand, is compulsory (you *have* to set the permissions everywhere) and simple. In modern kernels (I use 2.6) you can also have more detailed permissions (ACLs, capabilities etc.) but they don't seem to be popular.. 2. Wine now runs in userspace, needing no privileges to operate. That's great because it protects itself both from bas win32 apps and bugs Wine may have. If it needed to obtain more system power, it would have to be in rootland. I wouldn't feel comfortable knowing that a win32 app runs on my system with some kind of root privileges.
I don't feel comfortable running any non-essential programs as root or Administrator. I certainly don't run Internet Explorer or Outlook as Administrator. However, I think Wine will have the capability to host Windows services in the near future and they may need to be run as root.
3. There is a certain tradeoff between letting those permission-hungry apps (I recently came across an app that wanted to form its own ICMP packets) and being secure.
That is exactly the situation SELinux is suited for. It has an even finer grained control of privileges than Windows and would allow you to grant the user a limited set of "root" privileges that are needed for it to complete its task without giving the user the ability to write to '/'.
IMHO restricting userspace apps is one reason Unix is secure (eg. no programmer will try to write an app that stores its data at '/' catalog, win apps may require write to 'C:\' or 'C:\windows\').
No programs that write to 'C:\' or 'C:\Windows' would be installed by me on my own machine or on the company networks I have worked on. No programmer on Unix or Windows (in this day and age) should assume that it can write anywhere but the user's home directory. From a security model perspective Unix and Windows NT have the same level of security. Where they differ in security is that Windows tends to have so much more code exposed to potential attackers compared to most Unix systems.
I prefer being secure.
Rob
No programs that write to 'C:\' or 'C:\Windows' would be installed by me on my own machine or on the company networks I have worked on. No programmer on Unix or Windows (in this day and age) should assume that it can write anywhere but the user's home directory. From a security model perspective Unix and Windows NT have the same level of security. Where they differ in security is that Windows tends to have so much more code exposed to potential attackers compared to most Unix systems.
Hoping that my former employer (and certainly his customer) doesn't read this, but I once wrote a windows application that required to write to C:\ :-). And yes, it really got installed by quite a big company. It was before the eyeopening experience of finding api calls to retrieve the windows temporary directory :-). Robert
participants (4)
-
P. Christeas -
Robert Shearman -
Robert van Herk -
Steven Edwards