I was recently thinking about ReactOS, and how it compairs with Linux. Mostly because some of my favorite applications are unfortunately Win32 only (e.g. Miranda and Irfanview), and the preponderance of horrible Windows malware is keeping me on Linux. (ReactOS, for those not in the know, is an open source replacement for Windows XP, still in the alpha stage. More here. (http://reactos.org/)) The current direction ReactOS seems to be heading in is to use Wine for most of the graphical interface, on top of a brand new windowing system and a kernel that can handle Windows drivers. Now, this sounds great... But it's going to take a lot of work to develop. And meanwhile, we don't have a decent OSS Windows replacement. So how about we use XOrg and the Linux kernel? Those support plenty of hardware, and are fast and (mostly) stable. The idea is this: create a Linux distro (call it Winux) that starts Wine along with X. (Maybe have Wine compiled statically against the X libs for speed, or something.) Everything in the GUI, from the login manager to the desktop shell, would be a Win32 application designed to work under Wine; the default browser would be based on wine-gecko, etc. Windows applications could be installed on a per-user basis. In limited-user-world, everything would work through Wine and Wine applications (unless you decided to call up a Linux shell, for which there'd have to be an option). Root stuff would be done through the command line and text config files, as it should be. :) Now I know that's not newbie-friendly, but it would make things a lot simpler, I think; and anyway, the idea isn't perfect Windows compatibility, but an open source OS with good Windows compatibility in userspace. (Obviously, Windows drivers wouldn't work; but with Linux hardware support, they wouldn't be needed, and antivirus rubbish would be largely unnecessary, especially if AppArmor was thrown in.) And yeah... It would be a kludge. But I think it would be worth it. For a base Linux system... Well, the whole thing would center on the idea of using Win32 userspace applications in a Linux environment, so I think basing it on e.g. Ubuntu with the full repos would be unnecessary and maybe bad. Better to base it on something like Arch or Slackware, I'd say, just to keep things as simple as possible (the whole thing already being a kludge). But then, I've no experience as a distro maintainer, so my impression could be wrong. Anyway... What do you folks think of this idea? Feasible? Or just stupid?
Hi,> Anyway... What do you folks think of this idea? Feasible? Or just stupid?Well, to be honest I don't see the benefit of your proposal compared to an easy-to-use Linux-Distribution with proper wine integration. But if you like to create what you propose, I would curious watch the progress and outcome :) - Clemens
On Sat, 2010-03-06 at 15:35 -0600, Gullible Jones wrote:> Anyway... What do you folks think of this idea? Feasible? Or just stupid? >A major problem is the enormous number of system calls that Windows implements. Last time I knew the numbers, and it was quite a long time ago, Unix/Linux had under 300 kernel APIs while the contemporary version of Windows had 3500. This is a reason why developing Wine is such a problem. Windows has so many because it appears to be a fairly undisciplined development shop. Each new version's project team seems to have invented a whole new set of APIs because they could and to stamp their mark on it. However, to allow any older programs to continue to run, they still have to reimplement all the older APIs too. Is it any wonder each new version is so much more bloated than the previous one? I think it would take several orders of magnitude less work to write a new Linux kernel from scratch than it will to add all the Windows APIs to an existing kernel, whether as built-ins or as a translation layer like Wine. Martin
The wine desktop and web browser is rather minimal, but if you want to extend these or write a window manager for wine, have at it. The problem I see is that most Linux window managers offer such a vastly improved user experience over Windows, once a user discovers all the bells and whistles, I miss the point!
Gullible Jones
2010-Mar-07 20:26 UTC
[Wine] Re: Crazy (and just maybe awesome) idea: Winux
So I gather this idea would not be so good (especially security-wise), even if it were practical? Too bad. I had hoped someone might find it worthwhile, but if it's that stupid, well, I won't complain when people point it out. Though I do have to ask, how much Windows malware actually runs in Wine? Do file infectors like Virut run? How about fake antiviruses? [Laughing]
I know tripwire. Biggest flaw its not real time. fanotify will allow that to be changed at least part of the way for file-system operations. Second big problem with tripwire is false positives. SELinux guarding services you most of the time don't even notice. Since distributions who did the SELinux system did it right in the first place. Yes SELinux has 3 basic modes. Off, Limited protection ie protect only items like services and god darn paranoid. God darm paranoid is what most people know and fear. Selinux has some reasonable front ends out there these days. No more annoying that putting up with zonealarm on windows. There is also smack if you don't particularly like Selinux both are peer reviewed. Martin I have never had a DBMS system I have not been able to make work with SELinux. Note SELinux programmers concidered everything. SELinux profile writers don't always. http://sourceforge.net/projects/segatex/ makes correcting policies quite simple. http:~user/... I have done that stuff with selinux in place. Some distributions have it work from the start line. There is a learning mode you can setup for selinux these days for odd ball problems. Its part having the right tools for the job Martin. MS released an so called anti-virus that used CRC32 checksums back in the WFW 3.11 time frame . Only one problem CRC32 checksums could be colided simply so it was rendered useless.
James McKenzie wine really should never be used to run anti-viruses. Anti-virus is a host OS problem. You can sit wine on top of clamfs. fanotify that should hopefully merge this year will enable Linux side anti-virus better under it. I forget to say it also depends on the RDBMS you are running as well. http://wiki.postgresql.org/wiki/SEPostgreSQLv8.4 This beast exists that is Selinux friendly. http://wiki.postgresql.org/wiki/SEPostgreSQL Really there is a full SELinux compatible stack under development. Part of the issue with databases is there will to run secuirty different to the rest of the OS. There is even SELinux reaching up into the X11 server.
Issue is under 12 months there will be no need for wine to be able to run anti-virus programs from a Linux point of view. Ie Linux will be able todo the job for it. Wine does not really do windows permission structs that can redue risk of applications. Instead everything get told its admin Selinux work on user sand-boxing also is providing a reduction to risk path. Really the biggest problem for selinux in wine is wineserver and other server side parts. Same bug as RDBMS hard to sort out who is doing what. Transparency issue. Seeing data go in one side of a program and out the other get very hard when mult users are using the same service. This transparency issue is a problem with lot of orcale and ms sql clients running under wine. Ie wineserver sends some network traffic you don't know what application behind wineserver did it. This makes it extremaly tricky to create permissive firewall rules and the like. Ie all in or not at all. Yes a really bad thing. Even that you say looks like legitimate activity if can really see close enough most viruses give themselves away. Application profiles really limit what applications can do as legitimate activity so reduce risk. Double layers. If wine cannot spreed out threw the system it risk is reduced. Like you don't forget the lock doors just because you have walking patrols. selinux is the locked doors. anti-virus and items like tripwire are the walking patrols. You need both. Anti-viruses also will always miss a percentage. Sooner we get fully functional snaps-hotting as well the better. Ie the third layer good and regular back ups. Linux systems without wine I don't have to depend on hope. Ok People lose all non package install applications that were not on backups. There are ways to audit and clean data files. Ie remove all unknown executable parts. You can be sure at the end you did get it all. Windows is far to hard to audit. Simpler to nuke and start over with the windows parts.
James McKenzie> Actually, if a Linux or Windows system gets 'infected' it gets 'blown > away'. That is because you cannot ever be certain that all affected > files were removed, no matter what OS. Now, you can image any OS and > 'blow' it onto an empty hard drive. This is done all the time in > industry. The point is that there is a complete product suite to > monitor Windows systems, called SCCM/SCOM. I don't know of a similar > product for Linux, but there has to be one. This is where money is > really made....Myths again. There is more than 1 way to clear a system ie blow it away. Linux you can compare all application files install on a system to packages they came from and user data to backups and user data threw executable code clearing. Ie only stuff without macros scripts... left. It kinda impossible to sneak past a binary compare audit. This can be done due to Linux's package management. This is boot loaders kernels libs everything. All altered files from the infected system can be archived. Ie the reduces the size of the data to backup from an infected system to prevent the infection causing data loss. Basically it possible to reset a Linux system to as if clean installed and in the process recover all the altered files and setting from the system. Lot of poorly trained people will just blow a Linux system away like they did with windows. Why is doing the windows way bad. No good records and if something was installed by package and something is altered that should not have been hello we now have something to send to virus labs to develop a signature to locate viruses. Package compare is a great way of reducing the size of system backups as well by the way. I have run honeypots for years. Yes a simple more user-friendly interfaces need to be built todo this. Even with a windows honey put that does not take updates doing a full binary compare is how you sort out what attackers added to the system. Windows updates and applications updates not from a common source make binary auditing not an option. Linux does not have things like registry files that are hard to audit. It is fairly simple to sort out what config files in Linux own to each application. Nice thing about the audit method is the list of files removed can be inspected over time and valid ones brought back. We are not talking data destruction or needing large backups.
> Mmmmmm ... speaking as a Unix sysadmin: if a work Unix box got > rootkitted, I would in fact just blow it away and carefully restore > data from backups. It's not like reinstallation is that hard or takes > that long, and I'd feel much more reassured of my system's clean state > than I would trying to clean a known dirty one. Your mileage may vary.True for closed source to just blow away. Results from a binary audit. Is a system exactly the same as if you had clean installed. File permissions and all get cleared and reset. Binary compare method is slightly slower on the install. But it salvages data. Problem here is training. Running honey pots you have to be able to dissect the system. There is another reason why you run a package binary compare install. If you know a system is breached and nothing has been tampered with you know a reinstall of the same OS is going to get you no where. Something else has entered the system. Problem with the nuke method. You don't know how you have been breached. True-fully think about it. How can you protect self if you don't know where you have been defeated. I am way more unhappy with a nuked system than a binary compared. At least with a binary compared I have a list of files to go through to locate more information how the intruder got in. Yes the difference between people running honey pots. It is a higher level of training. I have seen people using the nuke method wonder why the attack keeps on coming back. Since the cleanly installed systems were not protected from the attack because they did not know the attack they were dealing with. Honey pot methods are highly useful tools. clamfs is practical under wine.
James Mckenzie This is the difference. If honey pot people followed you methods we would be tons of wasted drives. Excess cost. No effective for threat trapping. Full honeypot level includes a firmware audit. You are basically a stupid fool to a honeypot person say only way to be 100 percent clean is junk the machine. When there are no executable code left that has not been inspected there is no operational home for the virus. So virus is dead. A virus is only software not hardware. Firmware audits are extremely fun to perform after the fact. Its so much simpler with the main bios chip of a motherboard has been in a flash writer and backed up as a binary compare image. The you should never backup infected file is 100 percent invalid for people who do honey potting. We are after the infected files so signatures can be developed. Basically we are offensive system admins not just defensive. Achieving data from infected system allows drive to be clear and data for working out what the attack was to be intact. So drive become reusable. When you have 500+ machines to clean up being able to use 1 drive per 10 machines is one heck of a saving. Yes that is about the pack down so 50 drives vs 500. Generating comparative data between machines is also useful for locating attacks. Note altered files don't all have to be infected. The method you are following can be a higher risk. The back up of the files allow in cases that critical files created from the time of the last backup that was clean to infection to be attempted to be recovered. Ie if file cleanable of all forms of executable code. Process of stripping all executable code takes time. Longer than the time you normally have the system back up. My complete cycle for binary compare and back online with deb and rpm based systems is only 10% more on doing a clean install. Difference is that 10 percent more saves heck load on harddrives required. Basically what would you do if you had 500 machines and could only get 50 clean drives. The best part about this I can get lot more machines back online just from the materials in stores than you can. Ie 3 drives in stores 30 machines possible back online. Time is money true. The more machines that can be brought back on line the better. I am about to tell you the best part about my stunt. The evil thing is transparent. Diskless remote boot or Linux Terminal Serivces Project from recovery server means that a 500 machine network can be back partly usable in under 15 min of infection being detected. Even that the compare process on the harddrives in place has began. Sorry 500+ machine networks I am use to dealing with. Even running harddrive image restores of windows machines with Linux Terminal Services or Diskless remote boot providing user with interface to use their machines while the infection is cleaned out. Lot of staff can perform other duties as long as there system at least somewhat works. As you said downtime is important. Client sides of the networks I reduce downtime to basically nothing since I am not needing to physically work on the internals of the machine and the machine is at least part functional the complete time I am removing the problem. A software infection is a software infection. 12 hours of disruption to restore servers. Clients should be under 1 hour of non function if setup in advance for problem. With imaging by next day at worse client machines should be back online as if nothing happened. And the complete time the clients are being cleaned up by software . I can be starting the backup search and data recovery process against the possible infected data while rest of staff are already back on the job. Lack of protected firmwares are a worry to me. Nothing strange for me to have replaced the server bios chips with eproms instead of flash on ones without a physical switch. So that is not a threat location. The argument is that you don't have time. You have tones of time if you are setup right. 9/11/2001 has taught you guys nothing. Your processes to bring networks back to operational in case of client infect are far too long and labour consuming. The fear that backing up infected files is wrong prevents cost effective and equal result methods from being used.