Re: Different permissions for different network interfaces

[Daniel Gnoutcheff <daniel gnoutcheff name>]

(Simon, just to get you up to speed: you've picked the perfect time to
ask this question, since we're actually in the middle of revamping
how N-M manages connection settings, esp. in regard to how it manages
security restrictions. Our plans/scratch notes reside at
http://live.gnome.org/NetworkManager/RemovingUserSettings.)


On 07/14/2010 08:17 PM, Dan Williams wrote:
> Daniel, does this conflict at all with the ACL plans we have in
> place? My first thought was that this situation could be handled by
> making the ACL for the "first" connection be sysadmin only and
> locking that connection to the MAC address of the first ethernet
> device.  Then the user would not be able to deactivate it since they
> had no access to that connection.  THe second device would be wide
> open.  Is that a correct read of the solution we've chosen so far?
> That doesn't address whether the user can get status of that
> connection or not and thus see it in the GUI of course...

Yeah, this matches what I understood our plan to be. Unfortunately, some
issues remain.

One is auto(de)activation. We've got to make the "public LAN" connection
available for autoactivation even when sysadmins are not logged in.
Currently, I think our plans were that if a connection is not marked as
available to all users, then the connection would not be eligible for
autoactivation unless at least one of the logged-in users can view it.
Worse, we said that if none of the logged in users can access the
connection, then it is to be deactivated.

Thus, if the "public LAN" connection was made accessible only by
sysadmins, it would not be at all usable unless a sysadmin is logged in.

And here's another issue: suppose the DHCP server is having issues which
causes the "public LAN" connection to fail activation at startup. Then
N-M will go searching for other connections to activate. If *anyone*
created an autoactivateable connection that isn't device locked, N-M
will attempt to activate that connection on the "public LAN" interface.


I'm gonna need to think about this use-case some more, because it
totally blows up several assumptions I've been making.

For one, I'd been assuming that local users would always be able to
forcibily deactivate any connection (cable pull, killswitch, etc.). So I
had assumed that if a connection is available for autoactivaton when a
user is logged in locally, that user would already have a crude kind of
control over (de)activation of that connection. So I'd been assuming
that the "activate" PK action would mean little for local users and that
its main use would be to keep remote users from messing around.

Furthermore, I had kinda figured that local users could just swap wires
around as they wished, so I had been assuming that it doesn't matter
much (from a security POV) what hardware device is being used for a
given connection.

*But*, one could just build an enclosure that protects the "public LAN"
hardware from abuse but leaves the local-use interface free. So it *is*
possible to prevent users from deactivating, and it *does* matter which
interface is being used for activating.


One idea is to somehow have activation permission be keyed by device. We
might have one polkit action for (de)activating a device that is "user
accessible" and another for one that's "user inaccessible". Then we
could do this:

1. Mark the "public LAN" interface as "user inaccessible".

2. Only allow sysadmins to activate connections on "user inaccessible"
   devices.

3. The "public LAN" connection would be locked to that device, marked
   as available to all, and marked as read-only.

4. Mark the "local-use" interface as "user accessible".

5. Allow all local users to activate connections on "user accessible"
   devices.

6. Allow all users to "administrate" connections. (But since the
   "public LAN" connection is marked "read-only", they still won't be
   able to edit that one connection.)

This would all solve the issue of getting to the public LAN connection
to auto-activate when we want it to. But we still need to do some
permission enforcement at autoactivation time. I've still gotta think
about this.

Oh, and this would require we have some place to store per-device data.
udev could help there I guess.


Have a great one,
Daniel