wine users - Apr 2011 - creating built-in firewall for Wine

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.