iptables and path-based outbound rules?

I do not have access to it right now - too much of a hassle to whitelist it - but, couldn't it be because of Customer Experience Improvement Program?

I'm not sure if WMP privacy settings take care of this one issue?

 

I'm not sure, though in my case it shouldn't be because I've disabled it in gpedit.msc including participation in it as well as the Windows messenger aspect of it . Those Customer Experience settings are aslo scheduled for once/week or x number of days, but wmplayer is calling out on every startup.

 

No ambiguity.
To verify / reproduce:
-- run a freshly burned "live" version of kubuntu 12.10
-- double-click any music file + monitor your network traffic
-- scour the preferences/settings of that default "audio/*" mime handler app;note the pre-configured preference to callout to last.fm and various other sites.

FWIW, I'm not singling out kubuntu.
The same is observable for xubuntu 12.10, xubuntu 12.4, kubuntu 12.4, mint LMDE, etc.
The significance of the word PROBABLY, above, is that I have encountered a few distros released this past year which do NOT exhibit this behavior. The privacy-unfriendly behavior I've described is a distinct trend, observable in most of the (20+) recent distros I've test-driven.

my turn to ask: "Are you spreading FUD?"
Are you absolutely positive user "can disable" akonadi?
(point of confusion: if akonadi can definitively be "disabled", why did the kde dev invite "compiling the app(s) without akonadi support, if you wish")

For most users, "compiling from source" is certainly not an acceptable "choice".

First of all, as a matter of record: It's already been exploited (and patched, as followup).
Secondly, debian package maintainer(s) consider the webkit-enabled greeter to be unsavory & have chosen to exclude it.

no control:
Considering that many distros will prevent user from launching a web browser "as root" (danger Will Robinson!)...
...it's remarkable that some distros deliberately, nonchalantly, launch lightDM + webkit greeter prior to user session.
Casual user cannot "disagree" with this nonchalance. No gui utility is provided to change to a different greeter.

Perhaps the trend represents nonchalance, perhaps not.
Considering that canonical "was fine with" shipping a product that intercepts all users' web searches (uh, unless we opt out)(yeah, uh huh)... and that Mint omits an uninstaller for their "search enhancer" (and, IIRC, further enforces its presence via core package dependencies)... and the preconfigured music player callouts, along with seeing internet domains described, in app, as "partners"...to me, it seems reasonable to conclude that the current "desktop linux" distros are privacy-unfriendly.

I've posted in this thread to echo what the man said:
"wow, that's a huge bummer... Seems like a big gap in desktop security"
and to explain WHY, from my perspective, it seems like a "big gap".

 

Inka, thanks for the clarifications , much appreciated.

What private information is being sent to last.fm and other sites (I am not aware of any private information being submitted) ?

I believe you are talking about various plugins that are enabled - would it not be easier to disable them than resort to some kind of outbound filtering ?

aKonadi can be disabled (we could simply remove it) for sure (can't comment on how programs that depend on it would behave), just like you can manage every part of Linux.

Are you implying that using webit for the greeter enables some kind of internet access (I honestly don't know what the security/privacy issue is)?

What has a webbrowser got to do with the greeter ?

Casual user can disagree by not using.

Agreed that does suck for various reasons around the information sent, the information received and what canonical can do with it as it acts as a proxy.

Mint does a number of strange things IMHO, I've not use it for a long time, so what you say does not suprise me

Are you sure these are not conveniently preconfigured to get album art and info ?

I think its a stretch to call these few examples (of which some of your claims are still not clear to what the privacy issues are) a "big gap".

Cheers, Nick

 

With attention to the subject of this discussion thread, I was grousing about "music player" app (or its plugins)(please, lets not split hairs) being pre-configured to initiate outbound conections without user consent and/or knowledge. Don't rely on my representation as to "what private info is being sent?" -- wireshark your connection to find out. Whatever specifics I might provide here, based on your replies thus far I suspect you'd counter with "oh, that's not PERSONALLY IDENTIFIABLE info"... which is irrelevant. Private is private. The content of my file system is private. Which music tracks I play, and when I play 'em... is private. Repeatedly discovering apps which are pre-configured to surreptitiously violate my privacy (in my perception) has reinforced my desire for ability to apply "path-based outbound rules". On my system, music player does need net access, period... except (reiterating the point) in the current linux destop environment, that's not an option, user has no facility to enforce such control.

I am sure SOME of the callouts _are_ exactly that. (Yet, IMO this behavior should be opt-in, vs pre-configured and pre-activated unless you opt out.)
As for the other callouts, wtf is "fluendo" (and why should I care?).
I'm incensed by the behavior, without explicit consent, of an app telegraphing a play-by-play detail of my listening habits to various appX "partners".

"Partners" is their term, not mine. Remote sites described/labeled as "partners" begs the questions "partner of whom? to what end? monetization?".

Easier is not the point Even so, denying net access per-app seems easier than hunting down callouts (.config files, beyond just what may, or may not, be presented via an app's gui)(and worrying whether those prefs will, oh-so-mysteriously, be reset during future updrades)

Nope, "basket" KDE notes app (for instance) depends on nepomuk... which pre-depends akonadi. Another example -- konqueror, can you configure it to ONLY serve as a (local) file manager? Nope. It's web enabled, and it has unrestricted access to the nepomuk store. I don't have a concrete problematic example here, but it represents a vector begging exploitation.

If, in Synaptic package manager app, you "mark for removal" (but do not click apply) packages containing the nepomuk and / or akonadi libs, you'll see that nearly every kApp, from bookmarks manager, to password manager, to text editor... some of 'em for who-can-only-guess what reason, have inbuilt deps.
-=-
A similar issue (privacy exploit vector, ripe for exploitation) exists in the gnome environment. Although a user might disallow a music player plugin from initiating net connections, the manifest and details of his music collection is stored to gvfs-metadata store ~~ user has no facility to monitor/control which apps scrape whatever data from the datastore.

Not "implying" -- stating an actuality.
Today your pre-installed, webkit-enabled greeter might just be utilized to "paint a pretty picture" (html canvas animated backdrop) or to facilitate rendering of a designer's eye-candy... tomorrow, your distro mothership might have it check for updates (ping, Johnny's connected) or some other installed app may utilize the greeter's functionality to callout to check the weather report (or any other remote host, via http protocol).

^--- ref: launchpad.net/lightdm-webkit-greeter
retrieve "lightdm-webkit-greeter-0.1.2.tar.gz"
inspect "lightkit-webkit-greeter.c" line 1061
Note that it renders index.html without knowing/caring whether that page requests assets from remote URIs
(nor does it consider whether the requests contain GET or POST data).

That truism nicely underscores the "forced choice" of the status quo.
It's free FREE free. Take what we "give" you, as a package deal... or don't.

Well, I could have explained the details a bit better.
One of the core Mint packages (vs a separately uninstallable package) "seeds" user's system by placing in /opt
configs for firefox, for chromium, and for opera
so that the uninstallable-via-gui "enhancer" is imposed upon every user on the system who installs any of these browsers.
Further, they even handle the possibility that a user will install a browser sourced from a non-mint repository ~~ in that eventuality, the "enhancer" gets injected by an apt-get postintall trigger. In light of all that effort... should a user reasonably trust that his wish will be respected after clicking "thanks... but no thanks" (disable) in the gui?

For me, the central issue is that it (privacy trouncing) has become a "trend".
Canonical figgered "amazon/kindle gets away with it (proxying/monetizing) so we can too" ?!?

Regardless how we each perceive the "size (and significance) of the gap", the absence of an easily configurable app which empowers a linux desktop user to marshal outbound connections per-application is a (remarkable and) glaring omission.

 

I'm with Nick... you don't need an outbound Firewall to stop these things. It wouldn't even work well - Dangertux did a demonstration for trivially bypassing outbound firewalls and it shows fairly easily that attackers can just change ports to one that's open, and assuming you're connected to the internet you will have one open. If we're assuming these services are malicious (which you seem to believe) then it's not a large step to believe they're capable of going around a Firewall.

Much easier to just disable the feature in the Ubuntu Privacy Settings, disable all logging and reporting. It's all in a clean and simple interface.

 

Although a different O/S, I thought I proved earlier that even with the checkboxes cleared under wmp's privacy tab, it did nothing to stop it from calling home , yet I can easily block the callouts with an application control fierwall.

-EDIT-

And the same Dangertux you mention seems to advocate the use of strong outbound rules in iptables He does mention that although a strong firewall could be bypassed, he implies it would take a dedicated attacker to do so, and that at least the firewall with strong inbound/outbound rules will mitigate attacks. I agree

-http://ubuntuforums.org/showthread.php?t=1871177

 

I'm taking from DangerTux's blog, where he demonstrates how easy it is to bypass an outbound Firewall once you have compromised a process. It doesn't take a dedicated or advanced attacker, it takes a few extra lines of code to not fail when the port is closed and instead to look for another. If it's application specific you just use the trusted process to bypass it. The only way this won't work is if an attacker has somehow compromised a local process that doesn't have outbound network access and is running in its own UID.

His blog is down/ perhaps he's no longer using it. That's unfortunate since the post shows how simple it all is.

Can't speak to WMP.

 

I won't dispute he demonstrated it can be done, but of interest to me is the phrase: "once you have compromised a process". If in fact a process first has to be compromised for it to happen - never mind what must happen to spring the malware into immediate action - then this is where I wonder under what conditions are required for a process to be compromised in the first place, and if the end user has taken proper precautions to harden their setup against this part of the malware attack, then maybe the firewall bypass and anything else the malware might leverage to its advantage becomes not so trivial after all?

I have no idea about the test setup used, except that it could easily be better demonstrated as being "trivial" if it was deliberately configured with weaknesses such as being several months behind on patches, overly liberal security settings in the affected applications, or the tester deliberately allowing suspicious actions that typically cautious users would never allow.

It's just that since wmp is doing this, who's to say it can't happen with other applications, whether they be MS or even Linux developed?

 

First thing I do is delete wmplayer from Windows so no worries.

 

It's actually quite interesting that everything is so easy to bypass, provided that certain conditions are met.

 

That's what it seems to boil down to

 

Just FWIW it turns out pathname rules did once exist in netfilter - back in the early 2000s. Under '-m owner' you used to have

--pid-owner

and

--cmd-owner

The latter is the one I would have wanted; it matched against a command name. Unfortunately(?) both options were later removed entirely, due to being broken on SMP systems.

That said, it's become clear to me that per-process firewalling is not a good approach to security vs. malware; it doesn't scale well to large numbers of applications, and furthermore it assumes that an attacker won't have shell access. So I can see why these options were never added back, and why none of the BSDs ever supported anything similar in the first place.

 

I'm glad you bumped this thread. I've been looking for such a firewall and am disappointed to see that these aren't available for linux.

No, not against actual malware, at least not by itself. That said, if "security" is expanded to include privacy implications, per-process firewalling would be quite useful for restricting undesirable behaviors of "legitimate applications", behaviors that are becoming more commonplace and more often enabled by default. Users who don't have prior experience with these apps aren't aware of these default behaviors and have no real way of finding out about them until after the fact.

Whatever happened to apps and operating systems that didn't send anything out until you wanted them do?

 

@wat0114, Re: your post#25

Yup, agree. In Windows XP, in the Kerio or Sunbelt firewall I allow local host in and out except on the Avast proxy port. WMP goes nowhere no matter what WMP's settings are.

@noone_particular,
Take a look at the Firestarter firewall and tell us what you think. It is in the Synaptic package manager list. They have a pretty decent manual. I think it's abandonware, but even though no green circle in the packages list, it works on Mint13-MATE without crashing the machine.

Not easy to setup, but easier than the native Linux firewall. It does allow setting in/out rules for services (ports), but I didn't see specific application rules. I think it's basically a GUI for the native firewall.
If you do take a look, and I'm not even sure it's close to what you're after, also consider this fix for logging to work
https://bugs.launchpad.net/ubuntu/ source/firestarter/ bug/776361/comments/2

 

Yes, that's exactly my point of view.
If it's more accurate to say "privacy considerations" instead of "security implications", or "HIPS" instead of "firewalling"... that's fine by me.

The thread title mentioned "path-based" rules... but discussion drifted to "per-process firewalling".

With akonadi bus (and its ilk) in the equation, I think "process-based" rules are a dead end.
Here's why:
If you install a recipe manager app, or a text editor, or whichever absolutely NON_network related app... I feel that you are entitled to know if/when that app is connecting to the network. If Nepomuk or equivalent is running (daemon process, with pre-authorized network access, probably granted superuser permissions at startup) its process represents a vector which can't be easily marshalled.

 

Thanks. I will give firestarter a look. Initially I was hoping to find something similar to Kerio 2.1.5 for linux but I see that's not going to happen.

The computer industry seems to treat security and privacy as separate. The first gets addressed, even bragged about. Privacy gets ignored or whitewashed. AFAIC, they're completely intertwined and inseparable. It amazes me how little value people put on controlling apps, operating systems, etc connecting out without the users approval or knowledge. Unless the user is monitoring outbound traffic at the time, and the app sends everything as plain text, there's no way to know what it's sending out. One only needs to look at "smart phone" apps to see just how intrusive and nosy an app can be. Whether we like admitting it or not, computer applications and operating systems are moving in that direction, linux included.

For all purposes, I'm just beginning with linux. There's a lot I have to learn. That said, the more I look at its security model, the more it looks incomplete and (I hate to say it) narrow minded. If linux is supposed to be about user freedom, why isn't the user free to control the outbound data from individual applications?

 

Because "such a firewall" is not needed, instead of trying to stop the horse after its bolted, why not keep the gate shut and use kernel level security such as apparmour or selinux.
This is a safer option as the code can't do anything destructive in the first place (such as wipe data, install rootkits etc).
]

Instead of worrying about fragile path/process firewall systems, why not disable the undesirable functionality ?

And how are these users going to have the knowledge to know what to allow and what to block, you just moving the decision they are going to have to make to a different place.

Cheers, Nick

 

I work in the field of data protection, privacy is about what other party’s are allowed to do and not do with your information. Security covers far more than just securing data, but systems, network, authorisation systems etc. They are highly related and a lot of common sense principles apply to both.

Have a read of the info on Wikipedia, gives a good general overview:
http://en.wikipedia.org/wiki/Computer_security
http://en.wikipedia.org/wiki/Information_privacy

Where is the evidence of there being a problem due to this "incomplete" security model?
What are the existing aspects of Linux security lacking ?

What restriction do you think there is preventing this outbound data control you desire ?
You are free to write the code you need, the fact no-one has does not mean there is any restriction of freedom, it could be argued it is not needed.

Cheers, Nick

 

For the paranoid among you:
http://superuser.com/questions/1799...ctive-firewall-for-outbound-traffic-on-ubuntu

In the three-answer post (second from the top), option 3 is the most flexible.

I will actually test this, for you tinfoil fans.

Mrk

 

More love for you:
http://sourceforge.net/projects/leopardflower/

Mrk

 

Leopard Flower generates graphical popups? LOL.

Re disabling connect() with a preloaded library, wouldn't that horribly mess up loopback communication?

 

I did not say it would work WELL or without errors.
But then, the original request is also somewhat nebulous, so.
Mrk

 

I'm not referring to malicious code, rootkits, etc. I'm sure that was clear in the 2nd statement of mine that you quoted.

By what means is a user supposed to know that such behaviors are present and enabled by default before they use the application? What mechanism is there that will alert me when an application wants to send data out for the first time? What prevents the next update for those apps from changing the settings back? What stops a new "user experience improvement" feature from doing this for the first time without my approval? On my Windows units, no application has internet access until I specifically allow it. When an app tries to connect out, the attempt is intercepted and I'm notified of it. What mechanism exists in linux that enables me to to apply default-deny to internet access on a per-application basis until I specifically allow it?
You say:
"why not keep the gate shut?"
I ask:
Why is this gate open by default?

Why is it a problem to have a single interface from which traffic can be controlled? It doesn't require much knowledge to determine that one app needs internet access and another doesn't. It certainly doesn't require as much as your last suggestion:
"You are free to write the code you need."
I didn't have to code my own firewall or HIPS for Windows. I didn't have to recompile files or route the traffic thru a sniffer to catch these default settings before they connect out. If that's what it takes to get linux to behave the way I want it, then I don't need it.

You pretty much answered that for me in your first reply. Security in the kernel seems to be all that's addressed. Sure, that stops malicious or destructive code. It doesn't do a thing about invasive or nosy code. What stops a media player from sending a list of your media files to the RIAA? What prevents a browser, IRC or IM app exploit/coding error from connecting out directly instead of routing through Tor, or leaking a DNS request? What prevents any user app from sending out any file you have? AFAIC, default-permit with outbound internet access is a gaping hole. Even if the kernel could be perfectly secured, the users applications are not. I don't see any way for a non-expert to do anything about it. I would expect that kind of behavior from Windows and the closed source apps that run on it. I didn't expect it with linux.

 

It's not a point that a trojan or something got in because I allowed it.

The point is that:
- Certain applications are part of the system and theoretically trusted, yet might not be in practice.
- Definitely not in windows.
- Sometimes one wants to restrict ports 80, 443...to specific applications and no other, like in Kerio.
- You may want to restrict email client app to specific ports and server addresses, but not allow the same mail ports for any other application.
Iptables, it looks like, would allow any app to go out once an outbound to those ports/services is permitted.