All apps are granted network access by default

[Bob Meyers]

In the same architectural spirit as:

https://bugs.launchpad.net/elementaryos/+bug/1559367

applications should have network access disabled by default. A button somewhere on the window's title bar, maybe next to the closing "X", should permit network access. Attempts to access the network without permission should result in a blocking dialog which halts the offending thread until the user approves access. (This would be the only way to handle command line apps seeking network access because they do not involve the GUI.)

Perhaps an exception could be made for apps seeking to access files located on NFS. In that case, the NFS wrapper itself constrains the format of the network traffic that an app may send, so in principle it's equivalent in safety to normal file system access, and can be allowed, provided that normal file access checks permit it. The kernel would see the request as a file access attempt, which only much later resolves to a network access, which need not be blocked. The intent of this proposal is to block apps from contacting specific internet destinations and sending user data to them without the knowledge of the user.

Note that the scope of this proposal is purely about blocking access. Dumping sent and received network traffic between the app and its remote peer would be a next step and the subject of another proposal.

[Bob Meyers (bobgmeyers)]

I just realized that command line apps can be treated the same as any other app. All that's required is the usual network accesss enable/disable switch in the corner of the terminal window. Any commands or other apps launched in that terminal inherit that network access status, just like a thread launched or forked from a windowed app. If several concurrent threads are launched from that terminal, then they are all simultaneously affected by the switch, even if its state is altered after the threads have launched.

There is also the question of how to select the default state of the switch. Initially, it should always be off. Then if it's enabled for app ABC, then all future instances of app ABC, even after the next reboot, should have it enabled. Similarly if it is disabled once again. This implies a simple setting in a registry somewhere which contains network switch defaults for each app.

[Aneurin Hall (aneurin-hall)]

It might be better to simply overhaul the firewall dialog: most of the features you're asking for could be achieved with a single switch to choose between a black or a whitelist in the firewall, even better permission can be stored so users don't have to deal with 100's of popups as the various moving parts that compose a unix-like connect or disconnect from the network.

[Bob Meyers (bobgmeyers)]

I appreciate your effort here, but I don't think an internet firewall is the right approach. Nobody actually knows which websites or internet addresses they can trust or not. For one thing, even benign websites might get hacked, spilling your data to a malicious third party.

To be clear, I'm not trying to solve the problem of untrustworthy websites. I'm trying to address the unnecessary provision of network access.

In my design, there would not be any popups, other than perhaps a display-once dialog just to inform the user of the existence of the feature. Any attempt to access the network would simply result in an error, similar to an error that would be generated when accessing a file without permission.

For example, my calculator does not need to connect to the network. I don't care if it has a bug because I can download a new version to fix it. Yes, it would be somewhat easier for me if the calculator updated itself from its home on the web, but allowing this to occur is not worth the risk that it's either incompetent about security or downright malicious. A network disconnect switch in the corner of the calculator (probably on its title bar) would be all that's necessary. (This button would not be visible to or controllable by the calculator itself.) The state of this button would be remembered across launches.

If you don't like the idea of a button, you could have an "app firewall" as opposed to a normal internet address firewall. You could allow the user to blacklist or whitelist apps, as opposed to internet addresses. This method would not involve user interface changes. By default, all apps could be whitelisted so users who don't care about security could just have things work as usual. This is undesirable from a security perspective, but it's probably necessary from a marketing perspective.

I suppose that part of the implementation problem is that obtaining network access is very similar to obtaining file system access, so there is no "open network" call that you can just block. (Well, if there is, then block it.) However, you could look at the file being requested to see if it starts with "http" or "ftp" in some mix of letter cases, for example. I'm not sure which specific OS functions are involved, but I assume that's well known.

This is not intended to be airtight. You have based your OS on Ubuntu's broken codebase, and conduct updates via HTTP, so there's no realistic hope for that. The point is just to kill as many backdoors as possible with as little effort and development time as possible. Sophisticated malware will still get in.

[Bob Meyers (bobgmeyers)]

One other thing that might help you is lstat. You can pull up the documentation on this C function using "man lstat". It refers to a POSIX standard macro, S_ISSOCK(stat.st_mode). This macro will tell you if a particular directory entry is a socket, as opposed to a file or a directory or something else. You could hook fopen and similar functions and first branch to lstat followed by this test macro. The hook itself would be installed, or not, per app instance.

If you go this route, I would reject anything that does not return true from S_ISREG, S_ISDIR, or S_ISLNK, as everything else is creepy in a hardware way.

Of course it's possible that a rogue app could take a more indirect route, for example, by following a link (S_ISLNK true) to a network socket (S_ISSOCK true), but again, this is about best efforts, not perfect security.