Users : Prevent program installation

[Prunkdump]

Hi

I'am the network administrator of a french high-school and I would like to give the same wine prefix to all my users.

Is there a way to prevent the no root users for installing new wine programs ?

Thanks !

Baptiste.

[dimesio]

I'am the network administrator of a french high-school and I would like to give the same wine prefix to all my users.

http://wiki.winehq.org/FAQ#head-f54d469 ... 0167919859

Is there a way to prevent the no root users for installing new wine programs ?

You can search the forum for various ideas people have posted to make it harder, but I don't know of any that will still allow Wine to work that can't be circumvented. As long as users have write access to somewhere they can create a wineprefix there and install anything they want.

[KenSharp]

I do this by having separate WINEPREFIXes for each user, and simply pointing shortcuts in the right direction.

This only works for simpler programs, anything that needs to heavily edit the registry during install will not work unless you first install, then copy the registries, or use copy-on-write.

It can be done, but it's a pain.

However, seen as you're working in a school it's definitely better to do all of this than having to pay licence fees for certain other operating systems.

Once you have it sussed it all works nicely. Remember though that if the applications uses .ini files to store user details that could also be a problem but.... copy-on-write - so long as you have plenty of disk space (depending on usage).

Let us know if you get it working though!

[oiaohm]

Prunkdump this is lot harder than you can dream.

dimesio

You can search the forum for various ideas people have posted to make it harder, but I don't know of any that will still allow Wine to work that can't be circumvented. As long as users have write access to somewhere they can create a wineprefix there and install anything they want.

dimesio is so correct here is not funny.

But I will provide some major extentions.

Point 1. Wine does not in most cases respect noexec. So a partition mounted noexec wine will still run binaries from it. This is a security flaw as a loader wine should detect noexec and fail to load.

Point 2. Only containment options is sandbox the hell out of wine. This goes as far as running cgroups or virtual machines.

Even so running windows has the same problems with lack of containment. I have never had a locked down windows machine that I have not been able to run rogue applications on one way or another.

There has never been any major investment in wine that focused on security. Even that I hear of schools and other parties using wine.

FOSS is mostly a free lunch but someone has to pay the bill. At times for some features you really need to start looking at how to split the bill for extras.

[Prunkdump]

I'am solved the problem of sharing the same wine prefix to all my users.

-> I export it with NFS as ReadOnly
-> pam_mount mount it to the users with aufs to have write access.

Seems there are not a main wine configuration file...

Maybe I can restrict access to the wine binary and let the users launching wine with previously made bash scripts. But how set the rights on wine, on the prefix and on the bash script...

I'am searching.

Baptiste.

[dimesio]

You might look into whether SELinux or AppArmor can be used to restrict the wine binary to executing only the apps you've installed.

[etwineb]

It is definitely possible with Tomoyo since you can limit how the program is called. In your case you have to limit wine calls from a known script written by you. About the other problem consider fuse unionfs.

[oiaohm]

dimesio Apparmor and Selinux and all other LSM are limited how they can contain wine. This comes down to wine disrespect of noexec flag on filesystems. So anywhere wine can read/write an executable can be placed.

Sorry the idea that you can wrap any LSM around a defective program and perfectly fix it is not true.

Mind you wine is not the only program on Linux with issue of disrespecting noexec so making it hard to contain users actions. There are a lot of interpreted languages that also fail to respect noexec.

Prunkdump wine is not your only threat.

[etwineb]

oiaohm, can you elaborate more?
I know only Tomoyo as LSM... But Tomoyo allows different rules depending how a program is called. In this case if it is called by a known script or in any other way.
If wine is allowed to be executed only via known scripts it cannot be used to execute any other win program.

I guess you can still compile a second wine in your home, but the system wine is secured. No?

[oiaohm]

etwineb you have to allow for a nasty little fact. .exe are not the only thing wine can run.

You don't need to go back to the command line to have a problem. Wine support jscript and some vba script. Both can in fact call .dll files. Like running MS Word or MS Excel both can load alien .dll files that could have been embed inside a word or excel document.

Noexec does need to equal Noexec or you have quite a few holes.

etwineb wine loader does not in fact run as a independent process to the application. So application reading a file it might be planing on executing sections of it or it might be a data file. This is where lacking proper noexec support becomes a big problem.

Yes you can prevent .exe to a point with LSM. But you cannot really stop user if they are evil/smart enough to inject one program over another. All they need is some weak point to run a dll inside something.

Its very simple to overlook injection. Injection prevention is simple if noexec works. Loader refusing to change stuff to exec status because it comes from noexec location. Yes this is required to stop a lot of malware.

Dll injecting avoids command line.

[Prunkdump]

What do you think about this method ?

I create à new "wine" group and change all the wine apps permissions so that only the root and this group can execute them.

I create a wine wrapper script with the setgid bit set on the wine group so the script can launch wine but with the right user name. This script force the wine prefix to .wine and check the wine command arguments.

On the aufs mount I remove the write right to all the "exe" and "dll" files so the user can't substitude them.

Baptiste.

[oiaohm]

Prunkdump you description is breaking rule 1 of wine.

Never ever run Wine as root.

Yes never ever run Wine as root can be enforced by apparmor, LSM and Tomoyo. On a server solution I would use the LSM (Linux Security Module) to enforce this. Infected wine in the past has ruined complete systems.

Some do the create a wine user.

Prunkdump windows is the world worst evil item. Dll files don't need to end in .dll under windows. Load-library under windows will load a dll with any extension added. To filter you have to use libmagic basically how file command identifies files.

http://en.wikipedia.org/wiki/File_%28command%29

Prunkdump its the programs you are using have to be audited to provide no loadlibrary option. a lot of Malware avoids ending Dll files with .dll. Also a lot of programs use unique extensions on there plugins dll under windows as well. Yes its one place Linux is highly consistent that a library is .so or the loader tells you to go get stuffed.

[Prunkdump]

No I don't execute wine as root ! I just put the setGid flag on the "wine" group to give wine access to the user through my launcher program.

I have the wine app :
-rwxr-xr-- 1 root wine 1039 Oct 3 2012 /usr/bin/wine32

and my wine laucher :
-rwxr-sr-x 1 root wine 6440 Dec 30 21:20 /usr/bin/wine-launcher

So the user can't execute wine directly but only with the wine-launcher. Bash script doesn't support setgid bit so I have to do a C program that unset the wine environment variables and accept only the args listed in /etc/wine-apps.conf.

-----------------------

I know that .exe and .dll are not the only things that wine can run. But the program installation is made by me. So I can lock all the files that don't disturb the program execution.

------------------------

I'am not a security expert but I can share the launcher source code for analysis.

Baptiste.

[oiaohm]

Prunkdump you don't need to state you are not a security expert. You are making some basic mistakes.

Code: Select all

ldd  /usr/bin/wine32

Last line I would expect to be /lib/ld-linux.so.2 this is the Linux Dyammic ELF loader.

Code: Select all

/lib/ld-linux.so.2 /usr/bin/wine32 --version

Magic right with only a read flag the program runs. Maybe enough missing x bits wine will die.

You are treating wine as if it is a sandbox as well its not. Wine applications can use raw Unix paths in places. So unless there is a cgroup or LSM sandbox around wine program running in wine could possible modify or access anything the user can. Particularly important with programs like MS Word, Excel... Programs that support scripts loading libraries.

From inside wine you can mess with wine environmental vars. Outside wrapper program is not really a valid option. Wine itself need to be patched to support restrictive environmental vars even possible if a config exists don't use environmental vars at all.

Basically I don't need to see source code because I can already see flaw in method.

There need to be some serous work on wine to support the kind of environment you are attempting to use it in. Wine was developed with the single user system in mind. Lot of constructs for a multiuser system and the security requirements are just not in wine.

[Prunkdump]

Oiaohm thank you very much for your help ! This is very instructive !

I'have tried your workaround on the real wine binary located on "/usr/lib/i386-linux-gnu/wine/wine.bin" and it works well ! I will try to understand why. If I remove the read right on the wine binary :

Code: Select all

ls -l /usr/lib/i386-linux-gnu/wine/wine.bin
-rwxr-x--- 1 root wine 20292 Oct  3  2012 /usr/lib/i386-linux-gnu/wine/wine.bin
ls -l /usr/bin/wine-launcher
-rwxr-sr-x 1 root wine 6532 Dec 31 10:02 /usr/bin/wine-launcher

The program won't start now :

Code: Select all

/lib/ld-linux.so.2 /usr/lib/i386-linux-gnu/wine/wine.bin --version 
/usr/lib/i386-linux-gnu/wine/wine.bin: error while loading shared libraries: /usr/lib/i386-linux-gnu/wine/wine.bin: cannot open shared object file: Permission denied

But the launcher still works.

You think that this security level isn't siffucient ? I know that wine have potentially security problems but how difficult is to find them ? ( ex : is it simple to change the wine environment variables internally ? )

Baptiste.

[oiaohm]

Prunkdump I can explain better.

• r for read: Read is all the loader requires to map to memory. Common mistake when disabling executable is failing to remove read so anyone know to ldd and find the loader can run it

• x for execute: is more interesting. You will find executable with x will run without read or write. This is because of special handling of loader so the loader can get read access even that user cannot

Changing environment from inside wine is really not hard. Take cmd inside wine its a full command line problem here is some programs disable cmd they cannot function either. Rock and hard place. Its not only messing with the environmental vars that can cause a lot of trouble.

http://wiki.winehq.org/UsefulRegistryKeys Now something using cmd is most likely using comspec in registry. Notice you can by altering registry tell it to load anything as cmd. No executable flag required. Read flag somewhere is good enough. Noexec mount flag does not work with wine so becomes a real pain really quickly trying to contain it.

Prunkdump if you like it or not you must Sandbox wine at a min. There are just too many ways for wine to reach out and touch something. http://blog.dotcloud.com/under-the-hood ... cloud-part has a bit of overview of cgroups. There are other sandboxing solutions on Linux.

There are questions. Do the users need to write rights to what wine creates. Yes just because wine creates it does not mean user needs write rights to that location.