Hello! I want to have firewall/monitor in wine. Configuring Linux firewall is an external solution that affects all programs etc. The idea is to create configuration file for black- and/or while- list that would be analysed by wine during connections requests. The brute way is to modify ws2_32 dll source directly, but maybe there is more accurate way. Could you suggest where to start digging? Is there any type of wine-extensions (AddIns) technique?
You should use a native firewall. See http://en.wikipedia.org/wiki/Iptables
On Mon, Apr 4, 2011 at 1:49 PM, Boriso <wineforum-user at winehq.org> wrote:> Hello! > > I want to have firewall/monitor in wine. Configuring Linux firewall is an external solution that affects all programs etc. >Really? You have to read what is available for TCPWrappers and how IPF Filters really work before making that statement. I know them, very well....> The idea is to create configuration file for black- and/or while- list that would be analysed by wine during connections requests. The brute way is to > modify ws2_32 dll source directly, but maybe there is more accurate way.I will state what Vitamin and DanKegel have already said about this, Wine does not support genuine Firewalling. However, what you ARE looking for is what Windows calls 'firewalling', that is limiting the ability for a program to access the Internet. UNIXs implement this through the TCPWrapper function and you are free to port this to Wine. It will be a huge task, but may be worth it as others have asked for the ability to do this. However, this is 'outside' the scope of the Wine projects goals, as the Windows Firewall is outside the technical scope of building/reproducing the Windows API/ABI from what I understand (I may be wrong at this point.)> > Could you suggest where to start digging? Is there any type of wine-extensions (AddIns) technique?Code is available via Git and is publically available for you to use (and modify to do what you want.) Again, building functionality like TCPWrappers for Wine is a large task/project, but you are always free to try to do so. James McKenzie
Maybe we're talking about different things. "Firewall" traditinally means "a network filtering device that makes decisions purely based upon network traffic". That's the kind of thing I pointed you to in my previous message. You might be thinking of the expanded definition used by Microsoft: "a network filtering device that makes decisions based upon what executable is trying to do the networking". Is that what you're after? The latter type of filtering is probably possible on Linux by using selinux or apparmor, and would be much more secure than trying to do it at the wine layer. Please give that a try.
On Thu, Apr 7, 2011 at 5:13 AM, oiaohm <wineforum-user at winehq.org> wrote:> >> In short because native firewall knows almost nothing about the program. (But I could be mistaken.) >> > > Linux firewall is able to do applications. ?Few different ways. >One: SELinux only exists on Red Hat type operating systems. Two: Can you prevent (and this is an actual case) IE from not accessing the Internet but allowing Firefox to do so using native Linux applications from inside Wine? If you can, details please as this is an actual situation that has been requested in a security mailing list. Yes, there is someone that wants to install IE7 inside of Wine, but block all access from that program to the outside world but wants to use Firefox from inside of Wine and allow access to the outside world. Right now they are using Windows Firewall to do this, but they want the perceived security of Linux. And they have been just about everywhere trying to make this work. See, it is EASY to say "You can do that", much harder to demonstrate how. James McKenzie
> SELinux only exists on Red Hat type operating systems.Where on earth did you get that idea? http://wiki.debian.org/SELinux
On Thu, Apr 7, 2011 at 1:15 PM, dimesio <wineforum-user at winehq.org> wrote:> >> ? SELinux only exists on Red Hat type operating systems. > > Where on earth did you get that idea? http://wiki.debian.org/SELinux >
James McKenzie wrote:> On Thu, Apr 7, 2011 at 5:13 AM, oiaohm <wineforum-user at winehq.org> wrote: > > > > > > > > In short because native firewall knows almost nothing about the program. (But I could be mistaken.) > > > > > > > > > > Linux firewall is able to do applications. ?Few different ways. > > > > Two: Can you prevent (and this is an actual case) IE from not > accessing the Internet but allowing Firefox to do so using native > Linux applications from inside Wine? If you can, details please as > this is an actual situation that has been requested in a security > mailing list. > > Yes, there is someone that wants to install IE7 inside of Wine, but > block all access from that program to the outside world but wants to > use Firefox from inside of Wine and allow access to the outside world. > Right now they are using Windows Firewall to do this, but they want > the perceived security of Linux. And they have been just about > everywhere trying to make this work.I did give this information. Of course its 1 wineprefix per application. Splitting wineserver actions to each application inside a prefix is kinda impossible it is a blender of messages basically. Splitting by prefix is possible. Even inside windows splitting all internal calls to windows out to there source application can be impossible. Filtering by sub-process is impossible to be secure. Filtering by Wineprefix on the other hand. Simple and works more securely than windows firewall does. Even under windows you cannot truly firewall an application. Since applications can talk to other parts of windows and have other applications do their requests for them. This is key information to pull it off. wineserver connects to a particular file inside a prefix. Applications runinside the prefix also touch files inside the prefix. Yes bad presume that a process itself has to directly talk to the internet. In example. If firefox is allowed and application is forbin application inside the prefix could get Firefox todo its dirty work. So allowing forbin application still to access internet. To do firewalling going down to the subprocess. wineserver and other things have to implement selinux like secuirty on restricting applications from being able to talk to each other. Now to make it work with selinux. You create a data protection rule inside selinux that anything touching data inside the prefix gets a selinux tag. That tag lines up with firewall rules. Bingo one contained application. Even better you can lock out accessing other wine-prefix directories while you are at it. Ie applications tag with 1 wine prefix tag cannot access a different prefix. This prevents applications picking up multi tags. So breaking the firewall. It does cause some minor annoyances of not being able to directly copy data from one wine prefix to the next. Basically is no different to-doing Multi level data secuirty. There are some selinux front ends that make doing this fairly simple. http://www.linux.com/learn/tutorials/421152:using-selinux-and-iptables-together This covers how to make iptables use the selinux tags. traffic shaping systems can be simpler. They take the application command line and path and apply filters. Traffic shaping systems are secuirty system neutral and interfaces to plug them in are part of the Linux firewall design. But still you have to work by wineprefix since wineserver does some network requests on behalf of applications contained in the wineprefix. So the subprocess and the wineserver are not truly 100 percent independent. Yes everyone those commercial Windows firewall programs you love and trust is truly busted. More a false sense of secuirty. The paths I am describing are true working secuirty.
Martin Gregorie wrote:> On Fri, 2011-04-08 at 12:59 -0500, Boriso wrote: > > > I think that some kind of script or internal Wine command would be > > great if it could create new Wine prefix and configure some > > restrictions in IPTables and/or AppArmor. > > > > > There is no relationship at all between the IPTables firewall and > Apparmor/SELinux[1]. > > The IPTables firewall is only concerned with controlling ICP/IP access > to a computer - both TCP/IP sessions and datagrams. It controls > incoming connections from external TCP/IP data sources and also controls > outgoing connections. Thats all it does. It neither knows not cares what > program is trying to make or receive network connections: it is purely a > perimeter guard. > > OTPH Apparmor/SELinux is concerned with extending control over the way a > specific program can access resources (files, etc.) provided within a > computer. SELinux adds labels to file system resources to implement > Access Control Lists (ACLs) that restrict access in ways that the file > ownership and associated read/write/execute permissions cannot. It > neither knows nor cares about network access apart from the trivial case > of specifying which users can connect to a network port. >Selinux is about labeling. Selinux is not like Apparmor. secmark makes iptable label and able to handle labels. Yes depending on what secmark label is on something can alter how iptables handles the packets. Access Control Lists in fact are not part of SELinux. SELinux is MAC. Access Control Lists are DAC. Two completely different levels of secuirty. Access Control Lists exist independent to apparmor or selinux. Selinux implements Role Based Access Control. This is completely different. Role Based Extends up to iptables with semark then into sepostgresql databases then into "X Access Control Extension". Yes Selinux can control even what applications you can copy paste between. Role Based Access Control fully on truly can control everything you do on a system. Role Based Access Control does not end in its implementations just with kernel space code. True iptable does not care about the application as such. Iptables with secmark does care if application receiving or sending has the right label. The idea that iptable is pure perimeter guard is wrong. Its more like an elevator control person who might not know exactly what is going on but knows you should be going to x floor due to having x room key. Now as long as people only have the correct door keys this is solid. http://wiki.postgresql.org/wiki/SEPostgreSQL_Introduction . There is no reason why wineserver could not have a Selinux compatible form. So allowing selinux tags/secmark to pass through wineserver and iptables respond correctly based on those flags. http://www.linux.com/learn/tutorials/421152:using-selinux-and-iptables-together Yes this is using the iptables secuirty section to pick up selinux tags to control the firewall. http://james-morris.livejournal.com/11010.html This is when the relationship between selinux and iptables started. Yes there is a relationship Martin Gregorie been one for over 4 years. Apparmor you are correct there is no relationship at this stage. Selinux you are way off. Secmark support is planned to be added to Apparmor at some point in future. They were hoping for 2.6.39 for Apparmor support of secmark but from what I have seen of 2.6.39 it still lacking it of course might have missed it. Basically in a year time using secmark with iptables could be common place. Both selinux + iptables with secmarks work as one. To provide a more secure system. http://www.freenet.org.nz/python/pyshaper/ This is a iproute2 front end. This is one of the other paths. This is application neutral. Runs into the same problem from wineserver of it not telling it who it working for. iproute2+iptables is another combination that can share labeling. iproute2 support for filtering compatible with wine would have been one of the valid paths to enable filtering. No back door way to sneak around this. Apparmor is not used by any officially enterprise distributions due to its lack of key features like no secmark support so does not pass DOD requirements. I really wish people who really don't know secuirty would not try talking on secuirty topics.