Weekly Edition
Return to the Development page
| |||||||||||||
Williams: When the Sun Shines We'll Shine Together
NetworkManager hacker Dan Williams has an overview of the new features in NetworkManager 0.9 on his blog. Among them: "When connected to a large unified WiFi network, like a workplace, university, or hotel, NetworkManager 0.9 enhances roaming behavior as you move between locations. By using the background scanning and nl80211 features in wpa_supplicant 0.7 and later, you'll notice fewer drops in connectivity and better signal quality in large networks. Most kernel drivers will now provide automatic updates of new access points and enhanced connection quality reporting, allowing wpa_supplicant to quickly roam to the best access point when the current access point's quality degrades and not before."
(Log in to post comments)
Williams: When the Sun Shines We'll Shine Together Posted Aug 25, 2011 21:11 UTC (Thu) by blitzkrieg3 (subscriber, #57873) [Link]
I'm waiting for mesh networking.
Williams: When the Sun Shines We'll Shine Together Posted Aug 25, 2011 21:30 UTC (Thu) by smadu2 (subscriber, #54943) [Link]
<ot>
When the sun shines, we'll shine together Told you I'll be here forever Said I'll always be a friend Took an oath, I'ma stick it out till the end Umbrella - Rihanna. </ot>
Sorry could not resist.
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 2:06 UTC (Fri) by leif81 (guest, #75132) [Link]
"If you switch and the new active user doesnt have permissions for a connection, its terminated."
So if I'm downloading something over my VPN and I switch users the download may cancel?
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 6:33 UTC (Fri) by Hausvib6 (guest, #70606) [Link]
As expected from a great program developed mainly for single user system.
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 7:50 UTC (Fri) by xav (guest, #18536) [Link]
Would you prefer if the other user could use your VPN ?
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 8:08 UTC (Fri) by dmk (subscriber, #50141) [Link]
I'd expect my VPN to stay open in the background _AND_ the other user not able to use it.
Oh, and also I'd like to have a pony.
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 8:14 UTC (Fri) by xav (guest, #18536) [Link]
Yes I know, I'd expect that too. But I don't think you can have access perms on network connexions in Linux right now. Unless you start playing with containers, but even then I'm not sure.
So NetworkManager's way looks to be as good as you can get.
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 8:50 UTC (Fri) by pfee (guest, #79072) [Link]
Consider the user switching story in reverse. A malicious user leaves a process running, now switch users to your good self and start your VPN. The previous user's still running process can now take advantage of the connections you've just enabled.
NetworkManager's connection permissions protect against interactive use of another user's connections, hence is useful if users only invoke tasks when sitting in front of the computer. However it shouldn't be considered particularly secure against deliberate attacks.
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 13:19 UTC (Fri) by mhy (subscriber, #44155) [Link]
The iptables owner module?
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 22:43 UTC (Fri) by nix (subscriber, #2304) [Link]
That doesn't help much with VPNs because it runs POSTROUTING.
Williams: When the Sun Shines We'll Shine Together Posted Aug 30, 2011 13:34 UTC (Tue) by robbe (guest, #16131) [Link]
Please explain.
For the sake of clarity: we are talking about client VPNs, where the host in question is the only one getting access, and it is not a gateway/router to the VPN.
Williams: When the Sun Shines We'll Shine Together Posted Aug 31, 2011 16:29 UTC (Wed) by nix (subscriber, #2304) [Link]
For a single-user VPN, you'd want to have a different default route (or some other class of route) for one user than for all others (otherwise everyone's packets would go via the VPN): this can only happen if the local machine is the one routing packets to the VPN, because if it's done by some other machine then there's no way it can tell what user originated the packets, as that is a piece of single-machine state not transmitted over the network.
You could do that with the owner match and firewall marks... only the owner match runs POSTROUTING, so it cannot insert a firewall mark until after the routing decision is made, at which point it is too late.
I'd actually like to be able to do this quite a lot, but it seems impossible with iptables as currently constituted (or really difficult, at least: e.g. anything that involves switching to the newfangled userspacey iptables thingy is far too large a change for me to countenance right now).
Williams: When the Sun Shines We'll Shine Together Posted Sep 2, 2011 18:17 UTC (Fri) by nlucas (subscriber, #33793) [Link]
Isn't this one of those cases selinux was designed for?
I have to say I never used it, but seems strange not to handle this kind of things.
single-user VPNs on multiple-user machines Posted Sep 8, 2011 20:20 UTC (Thu) by robbe (guest, #16131) [Link]
>[...], because if it's done by some other machine then there's no way it can tell what user originated the packets, [...]
Maybe CIPSO, but let's not go there. > You could do that with the owner match and firewall marks... only the owner match runs POSTROUTING, so it cannot insert a firewall mark until after the routing decision is made, at which point it is too late. It is valid in the OUTPUT chain as well. Just tested with iptables 1.4.8 and kernel 2.6.32: # iptables -t mangle -I OUTPUT -j MARK --set-mark 7 -m owner --uid-owner nnn # ip rule add fwmark 7 table 7 # ip route add table 7 default via x.x.x.x All packets from processes with uid nnn were routed via x.x.x.x as expected. > I'd actually like to be able to do this quite a lot, [...] Then I'm happy to correct you.
single-user VPNs on multiple-user machines Posted Sep 8, 2011 22:09 UTC (Thu) by nix (subscriber, #2304) [Link]
Oooo! Neat! I'll be using this shortly...
Williams: When the Sun Shines We'll Shine Together Posted Aug 29, 2011 12:41 UTC (Mon) by marcH (subscriber, #57642) [Link]
IP networking is not designed with that in mind; this has nothing to do with NetworkManager. There is only so much NetworkManager can do.
The end to end principle at the core of the design of IP states that the network should be as dumb and as open as possible and do as little as possible. Security (among other things) should be implemented at the ends and only at the ends (i.e., at the application level). You can argue whether the e2e principle is the best way to design networks, but for sure VPNs and firewalls and "HTTP-networking" are and will stay just poor hacks trying to work around this fundamental design choice. Just like any other hack, they will constantly run into design problems like this one here.
I bet you will get a pony before this problem is solved.
Williams: When the Sun Shines We'll Shine Together Posted Aug 29, 2011 14:06 UTC (Mon) by paulj (subscriber, #341) [Link]
Nothing stops two trusted systems exchanging security information about end-user IP flows over IP, and keeping packets segregated from users and services with different sensitivities. In that context, it's a reasonably solved problem. Standardised extensions exist for IPSec:
Trusted Solaris:
http://download.oracle.com/docs/cd/E19082-01/819-7309/txn...
There was a Linux project (don't know if it integrated):
http://lwn.net/Articles/204905/
Williams: When the Sun Shines We'll Shine Together Posted Aug 29, 2011 15:56 UTC (Mon) by marcH (subscriber, #57642) [Link]
This is an awkward hack because the security is configured externally without the application (= the "end" in the e2e principle) even realizing it.
Quoting your reference:
No surprise everyone is using real _end to end_ security (SSL, passwords,...) instead of or in addition to VPNs/IPsec/etc.
Williams: When the Sun Shines We'll Shine Together Posted Aug 31, 2011 9:28 UTC (Wed) by geofft (subscriber, #59789) [Link]
You know, if you clone(CLONE_NEWNET) in a PAM module, you can probably have your pony.
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 17:51 UTC (Fri) by jspaleta (subscriber, #50639) [Link]
i believe VPN connections can be marked system wide just like other network connections with system admin privledged interaction to mark them as such. I believe system wide connections survive the user switch. It's only private connections which get cut off. I think. That would be a very good thing to check. I would expect all connections marked in the NM config UI as "available to all users" to survive the switch, including VPN connections thus marked.
-jef
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 10:40 UTC (Fri) by robert_s (subscriber, #42402) [Link]
Thankyou. I was just about to post similar sentiments.
Though I think of it more as someone else coming along and needing to log in, causing a download to be axed.
I think the situation seems funny because the less privileged user shouldn't be able to alter the system state, screwing up my operation in the process.
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 13:08 UTC (Fri) by Yenya (subscriber, #52846) [Link]
How do you (plan to) handle multi-seat systems? Thanks!
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 13:33 UTC (Fri) by maderik (subscriber, #28840) [Link]
Do multi-seat systems need a dynamic network manager that can switch interfaces as connections come and go?
Williams: When the Sun Shines We'll Shine Together Posted Aug 27, 2011 15:46 UTC (Sat) by bronson (subscriber, #4806) [Link]
Multi-seat systems need to realize that they are multi-seat systems. It's unrealistic to expect them to have 100% of the features of single-seat systems.
There are two sane ways... Posted Aug 26, 2011 16:18 UTC (Fri) by khim (subscriber, #9252) [Link] Either you keep everything really separate (this means VPN still works but the active user can not use it) or you don't pretend to offer such capabilities at all. As already was pointed out current solution makes life miserable for user without offering any security - thus it's the worst solution imaginable.
Williams: When the Sun Shines We'll Shine Together Posted Aug 26, 2011 19:30 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Uhm?
You can mark a connection as 'system'. It can then survive logouts and user changes. Of course, marking connection as 'system' needs sufficient privileges (mediated by PolicyKit).
|
|||||||||||||