creating built-in firewall for Wine

Boriso · Post by **Boriso** » Mon Apr 04, 2011 3:49 pm

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?

Post by **DanKegel** » Mon Apr 04, 2011 6:41 pm

You should use a native firewall.
See http://en.wikipedia.org/wiki/Iptables

vitamin · Post by **vitamin** » Mon Apr 04, 2011 8:31 pm

Boriso wrote:I want to have firewall/monitor in wine. Configuring Linux firewall is an external solution that affects all programs etc.

Wine can't have any firewalls. It's a 100% user space program without any abilities to sandbox: http://wiki.winehq.org/FAQ#head-f566a12 ... 13a773c571

Even if modified Wine will have such a "firewall" nothing can prevent windows program from directly calling system for unrestricted network access.

Boriso · Post by **Boriso** » Tue Apr 05, 2011 1:30 am

vitamin wrote:
Boriso wrote:I want to have firewall/monitor in wine. Configuring Linux firewall is an external solution that affects all programs etc.
Wine can't have any firewalls. It's a 100% user space program without any abilities to sandbox: http://wiki.winehq.org/FAQ#head-f566a12 ... 13a773c571

Even if modified Wine will have such a "firewall" nothing can prevent windows program from directly calling system for unrestricted network access.

According to the Wine architecture here http://www.winehq.org/site/docs/winedev-guide/x2591 "Wine must at least completely replace the "Big Three" DLLs (KERNEL/KERNEL32, GDI/GDI32, and USER/USER32), which all other DLLs are layered on top of. But since Wine is (for various reasons) leaning towards the NT way of implementing things, the NTDLL is another core DLL to be implemented in Wine, and many KERNEL32 and ADVAPI32 features will be implemented through the NTDLL."

Moreover there are some Wine dlls that could replace Windows ones. I think that ws2_32 is one of them. So running (under Wine) program would ask ws2_32.dll.so for network activities and could be filtered somehow.

I heard that "Wine Is Not an Emulator", but emulator of what? It is not emulating processor or something like this, but it substitutes PE loader, important dlls and so on.
Without dlls Windows program couldn't live and Wine is able to substitute any dll functions. Am I right?

vitamin · Post by **vitamin** » Tue Apr 05, 2011 8:36 am

Boriso wrote:Without dlls Windows program couldn't live and Wine is able to substitute any dll functions. Am I right?

No, you are not. Wine can not stop windows program from calling 'int 0x80' - direct call into Linux kernel.

Boriso · Post by **Boriso** » Tue Apr 05, 2011 9:03 am

vitamin wrote:
Boriso wrote:Without dlls Windows program couldn't live and Wine is able to substitute any dll functions. Am I right?
No, you are not. Wine can not stop windows program from calling 'int 0x80' - direct call into Linux kernel.

Sorry, but I do not understand what are you argueing with. I said that
1. There are no Windows programs that use no dll.
2. Wine is able to substitute any dll functions.

What is wrong? You know how to write Windows programs without dlls?

Post by **DanKegel** » Tue Apr 05, 2011 9:29 am

Why don't you want to use a native firewall?

James McKenzie · Post by **James McKenzie** » Tue Apr 05, 2011 10:00 am

On Mon, Apr 4, 2011 at 1:49 PM, Boriso <[email protected]> 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

Post by **DanKegel** » Tue Apr 05, 2011 2:26 pm

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.

Boriso · Post by **Boriso** » Wed Apr 06, 2011 2:43 pm

DanKegel wrote: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?

Yes, I was looking for ability to filter network actions for particular programs.

I'm new to Linux, so from my view network packet filtering is made by hardware router, but additional programs could provide filtering based on filtering. Although on windows firewall was one of the first software type I installed, but under Ubuntu I still did nothing about it...

DanKegel wrote: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.

SELinux and AppArmor are great, but could they be easily used for specific programs running under Wine? So you can start different programs and they would have different restrictions?

DanKegel wrote:Why don't you want to use a native firewall?

In short because native firewall knows almost nothing about the program. (But I could be mistaken.)

Here is an example. Some windows internet security programs ("firewalls") have a module that could be used for ads filtering. In the simplest form they filter traffic based on keywords and image sizes. The same could be done with AdBlock add-in for Firefox, but the flexibility of the later is greater. Moreover one could use very smart rules, because ads are filtered where they must be presented (in browser).

oiaohm · Post by **oiaohm** » Thu Apr 07, 2011 7:13 am

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.

http://www.linux.com/learn/tutorials/42 ... s-together This is one way having selinux tag the approved applications then iptables allow or forbid based on tag.

Next is decanted user or group using "-m owner --uid-owner myappuser" or "-m owner --gid-owner myappuser"

Finally is traffic shaping systems for Linux these are normally based on Iproute2 this is the most flexable and alterable on fly. http://www.freenet.org.nz/python/pyshaper/ Just one of many. They are designed particularly to join into default firewall of Linux and expand its functionality. Particularly to applications.

Basically a traffic shaping systems close the gap up completely. Application you want to have no access to the network you just tell it to be so.

Part of the issue is knowing that per application controls is not called firewall but traffic shaping or traffic control. Firewall assists traffic control but is not a traffic control system. Yes I know strange. Takes a while to get head around what that means.

Basically what you call a firewall under windows is a firewall + traffic shaping/control. Linux with a traffic controller/shaper is just as functional. Of course for a lot of routing devices Linux does not need the overhead of firewall + traffic shaping/control. So they are two parts.

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.

Here is an example. Some windows internet security programs ("firewalls") have a module that could be used for ads filtering. In the simplest form they filter traffic based on keywords and image sizes. The same could be done with AdBlock add-in for Firefox, but the flexibility of the later is greater. Moreover one could use very smart rules, because ads are filtered where they must be presented (in browser).

Linux iptable modules can do this. Transparent proxy option. http://www.review-ninja.com/2008/08/tra ... ables.html Of course that is every application and then you can use adblock plugins into proxy server like squid.

You can transparent proxy pop imap and other things as well for scanning.

This is not application targeted as such. But with the other options like selinux or users and groups it can be.

Boriso simple fact of the issue if windows can do it with networking so can Linux normally just a different way.

There is zero reason to be needing to use any Windows firewall parts once you understand how to make the Linux firewall and shaping systems fully functional.

In fact with transparent proxy features and other items you can build a system that is more functional than the most expensive windows internet secuirty programs. At zero cost.

James McKenzie · Post by **James McKenzie** » Thu Apr 07, 2011 9:28 am

On Thu, Apr 7, 2011 at 5:13 AM, oiaohm <[email protected]> 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

Post by **dimesio** » Thu Apr 07, 2011 3:15 pm

SELinux only exists on Red Hat type operating systems.

Where on earth did you get that idea? http://wiki.debian.org/SELinux

James McKenzie · Post by **James McKenzie** » Thu Apr 07, 2011 3:28 pm

On Thu, Apr 7, 2011 at 1:15 PM, dimesio <[email protected]> wrote:

SELinux only exists on Red Hat type operating systems.
Where on earth did you get that idea? http://wiki.debian.org/SELinux

From the folks on the Fedora Users List. Next time, I'll do a fact check...

However, SELinux still will not do what is needed, from what I gather.
However, I'll have to look at the documentation and see if it will
shut down Internet access for a subprocess (Wine is the process, the
Windows executible is the sub-process).

James McKenzie

oiaohm · Post by **oiaohm** » Thu Apr 07, 2011 7:15 pm

James McKenzie wrote:On Thu, Apr 7, 2011 at 5:13 AM, oiaohm <[email protected]> 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/42 ... s-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.

Boriso · Post by **Boriso** » Fri Apr 08, 2011 1:33 am

James McKenzie wrote: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.)

I looked through http://wiki.winehq.org/CategoryToDo and found no firewall or something similar, but here http://wiki.winehq.org/WineReleaseCrite ... eleasePlan one could find that "Wine add-ons" are already suggested and this is great. I think that Wine add-ons could made contributions more intensive.

In my opinion Wine is open but not very friendly with sharing information about the project. For example, there are many TODOs, wishlists, information about architecture, user manuals and so on. But there could be some pdf booklet or presentation (even in flash) that explains how Wine works, what are pros and cons, what is left to do.
This is kind of a marketing, but good external package is also important. In case you are talking about people who already know everything about Linux, Wine they do not need anything more, but for novices (like me) and ordinary desktop Linux users it is also important.

Anyway, I got many useful information from this topic. I also tested my idea about chaging ws2_32.c and it works fine. Now I'm going to examine Wine deeper.

oiaohm · Post by **oiaohm** » Fri Apr 08, 2011 2:51 am

Boriso wrote: I looked through http://wiki.winehq.org/CategoryToDo and found no firewall or something similar, but here http://wiki.winehq.org/WineReleaseCrite ... eleasePlan one could find that "Wine add-ons" are already suggested and this is great. I think that Wine add-ons could made contributions more intensive.

Reason zero point. Native firewall is good enough for what they provide. Wine transparency to native system firewalls could be improved. Native firewall uses does not leave flaws particular if it used how I directed.

In my opinion Wine is open but not very friendly with sharing information about the project. For example, there are many TODOs, wishlists, information about architecture, user manuals and so on. But there could be some pdf booklet or presentation (even in flash) that explains how Wine works, what are pros and cons, what is left to do.
This is kind of a marketing, but good external package is also important. In case you are talking about people who already know everything about Linux, Wine they do not need anything more, but for novices (like me) and ordinary desktop Linux users it is also important.

There is the wine users guide. Documentation is a problem. We are desperately short of technical writers. We don't have the personal to write the PDF or create presentations and keep them upto date. We have enough trouble keeping the http://www.winehq.org/docs/wineusr-guide/index staffed as well as keeping the FAQ correct

Lots of the pro and cons we really don't know how long they will stay true.

wishlists most developers don't read. Better as feature requests in the bugzilla.

What left todo at least the 6000+ open bugs to close is what left todo.

Anyway, I got many useful information from this topic. I also tested my idea about chaging ws2_32.c and it works fine. Now I'm going to examine Wine deeper.

Don't expect this integrated. Your path is purely the wrong way. For the simple reason there is no requirement in wine design for future network interface features to pass through ws2_32.c. You are basically setting self up for bruising. Wine dll.so files only have to use windows path pf dlls above them to perform tasks if programs could be effected. So mshtml emulation lot of places that could be coded going directly to the Linux network stack. So ws2_32.c would not see those requests.

This is purely performance based. Yes this global picture is wrong > http://www.winehq.org/site/docs/winedev-guide/x2591 <. ws2_32.c most operations don't go up to wineserver or follow NT design so are caught by using native traffic shaping. Instead ws2_32.c is a jump to native system dll.so. Other items that are jump to native include wine opengl implementation it avoids following the NT design. Lot of things inside wine don't follow NT. Instead follow the fastest path.

There needs to be extra boxs added to http://www.winehq.org/site/docs/winedev-guide/x2591 marking dll.so ie wine dll files that jump straight out to the native platform. Wine is permitted to short cut to native where suitable. This complete stuffs your method of filtering Boriso. There are going to be holes in your filtering.

Transparency to native firewall is an issue. I provided the instructions that work around that issue. Your alteration still does not address the fact the native firewall cannot see the process wineserver is acting for at times.

Its very pointless storing fire-walling data twice and having the filtering processed in two locations.

Boriso · Post by **Boriso** » Fri Apr 08, 2011 12:59 pm

oiaohm wrote:
Anyway, I got many useful information from this topic. I also tested my idea about chaging ws2_32.c and it works fine. Now I'm going to examine Wine deeper.
Don't expect this integrated. Your path is purely the wrong way. For the simple reason there is no requirement in wine design for future network interface features to pass through ws2_32.c. You are basically setting self up for bruising. Wine dll.so files only have to use windows path pf dlls above them to perform tasks if programs could be effected. So mshtml emulation lot of places that could be coded going directly to the Linux network stack. So ws2_32.c would not see those requests.

I'm using Ubuntu for several months and haven't installed Wine before because I had no understanding how it works and what are advantages for me. Now I tried to solve one problem and predicted that Wine could help and firewall was just a single point. Eventually I tried to do something and became more familiar with Wine.

oiaohm wrote:
Boriso wrote: I looked through http://wiki.winehq.org/CategoryToDo and found no firewall or something similar, but here http://wiki.winehq.org/WineReleaseCrite ... eleasePlan one could find that "Wine add-ons" are already suggested and this is great. I think that Wine add-ons could made contributions more intensive.
Reason zero point. Native firewall is good enough for what they provide. Wine transparency to native system firewalls could be improved. Native firewall uses does not leave flaws particular if it used how I directed.

Thank you for your directions, I'll try because security important even without Wine. But I have no experience before in IP Tables configuration. I also find on another forum a configuration file for AppArmor to prevent Wine for particular PREFIX access folders that are not belong to an installed application. 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. In this case security of Wine itself would increase.
Anyway, your explanation must be placed somewhere in wiki here, so it would become real tutorial someday.

oiaohm wrote:
In my opinion Wine is open but not very friendly with sharing information about the project. For example, there are many TODOs, wishlists, information about architecture, user manuals and so on. But there could be some pdf booklet or presentation (even in flash) that explains how Wine works, what are pros and cons, what is left to do.
This is kind of a marketing, but good external package is also important. In case you are talking about people who already know everything about Linux, Wine they do not need anything more, but for novices (like me) and ordinary desktop Linux users it is also important.
There is the wine users guide. Documentation is a problem. We are desperately short of technical writers. We don't have the personal to write the PDF or create presentations and keep them upto date. We have enough trouble keeping the http://www.winehq.org/docs/wineusr-guide/index staffed as well as keeping the FAQ correct

Lots of the pro and cons we really don't know how long they will stay true.

wishlists most developers don't read. Better as feature requests in the bugzilla.

What left todo at least the 6000+ open bugs to close is what left todo.

I still don't see a main target of the Wine Project.
Would you become happy if I say that now only 5000 open bugs are left? And what to do when there would be no bugs left?
Could you provide any milestone dates and bugs decreasing prediction?
Maybe these bugs could be left and movement started to the REAL target? Of course if process for process is not the main target.

I just want to understand how to estimate the distance between current and desired situations.

`Would you tell me, please, which way I ought to go from here?'
`That depends a good deal on where you want to get to,' said the Cat.
`I don't much care where--' said Alice.
`Then it doesn't matter which way you go,' said the Cat.

Martin Gregorie · Post by **Martin Gregorie** » Fri Apr 08, 2011 2:35 pm

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.

[1] There are two implementations of this security tool, which was
originally designed to bring Linux installations in line with DOD
requirements. Apparmor is used by some distros and SELinux by others.

Martin

oiaohm · Post by **oiaohm** » Fri Apr 08, 2011 11:07 pm

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/SEPostg ... troduction . 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/42 ... s-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.