The one known as "Steven Edwards" hath scripted: --------------------------------- 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) -----------------------------------
Looking at security from a Unix up to windows through WINE as opposed to looking down to UNIX from Windows through WINE, I have do disagree. The UNIX security system is not really "outdated" just "diffrent". One of the reasons why it's still around after 20 years is because it works.
As I have never owned Windows after ME drug it's carcass across the computing landscape, I don't really quite grok windws security anyway. From futzing with an XP box at work, I don't see any real obvious way of locking down permissions on files and such. Right click/properties on a file gives me the same tierd DOS flags that haven't changed since DOS 3.0 I don't see anyting that's blocking me from deleting, say, advapi32.dll with extreame prejudice. If I went into my /lib dir and tried a rm -fr as a normal user, my system will kindly tell me to go away and play in my /home directory.
The question is quite intresting. How does one "translate" a security philosophy? Do we want to give WINE the ability to hijack wsock32.dll? (wsock32.dll.so) This is often done with ISP proprietary installers, *COUGH*-AOL-*COUGH*, and various spyware apps.
Has this been considered?
Joshua Walker wrote:
From futzing with an XP box at work, I don't see any real obvious way of locking down permissions on files and such. Right click/properties on a file gives me the same tierd DOS flags that haven't changed since DOS 3.0
I've allowed myself to change the order of quotes a little. Sorry.
Joshua - your work XP was installed on FAT filesystem. If it were NTFS, you would have had a list of ACLs (Access Control Lists). This is a list that says "A can do this, B can do that, C is not allowed to do those" etc. It gives 100% granularity on what each entity can or cannot do, with each file, registry entry and device in the system. This, I believe, is what triggered Steven to say:
The unix security design of users and groups with permissions is not bad its just outdated.
Of course, Steven is, in my very humble opinion, dead wrong here. Windows' security model is a gross violation of KISS (keep it simple, stupid). Granularity is set so high, it is practically impossible to actually get anything configured. When was the last time you saw ANY windows program installer that changes the file permissions in any way? Last I checked, the standard installshield and wise template builders didn't even have an option to do that! In other words, we should not aspire to bring Window's security model into Linux. All the Windows security model did was cause every single user on the system to be an administrator. Having said that, we are left with Joshua's question
The question is quite intresting. How does one "translate" a security philosophy? Do we want to give WINE the ability to hijack wsock32.dll? (wsock32.dll.so) This is often done with ISP proprietary installers, *COUGH*-AOL-*COUGH*, and various spyware apps.
Has this been considered?
Here is my answer: At the moment, Wine is only aimed at single users installations. As long as that is the case, each wine user is an "Administrator" over his own fake-root wine installation. I don't see that changing.
I do want to see wine evolving into a (Linux) system wide installation, at which point security will have to come into play. I did post one idea on how to do that at http://www.kerneltraffic.org/wine/wn20030328_163.html#5, and in particular at http://www.winehq.com/hypermail/wine-devel/2002/10/0654.html (October 2002!).
IMHO, the idea should be to bring Unix simplicit permissions to the Windows world, at least for the Unix installations of Wine. Reactos may well legitimately want the full blown stuff, with all the security problems that come with it. This means that we do translate the Posix users and groups into ACLs, but we do not necessarily do it the other way around. Let's not forget that the purpose of Wine is to bring Windows apps into the Unix/Linux world, not to change Unix/Linux itself.
Shachar