I originally sent this e-mail to nwam-discuss, but I was advised that I should
also solicit input from the security community.
I've now included the original messages below,
Thanks,
Darren.
-------- Original Message --------
Subject: NWAM UI and Security
Date: Fri, 07 Sep 2007 16:28:26 +0100
From: Darren Kenny <darren.ke...@sun.com>
To: nwam-discuss <nwam-discuss at opensolaris.org>
Hi,
In working with a UI that is meant to configure NWAM, there is a need to
be able to allow/restrict who may perform this configuration. The main purpose
of this e-mail to to try gather some information from people that have a
vested interest in NWAM, that would help use to make this work as good as
possible...
The NWAM UI as a whole, has 3 main elements to it:
1) Modified GNOME Netstatus Applet with WiFi support
Right now, on Solaris, the GNOME Netstatus Applet doesn't have the ability
to display any status information w.r.t. a wireless network.
This is mainly due to wireless only being a recent addition to Solaris, but
also there is the inability to get status information about the wireless
connection, using an API, without the PRIV_NET_RAWACCESS privilege.
Naturally, this is certainly not a privilege that we want to give to just
anyone (since it would allow snooping to occur).
So the question is how to achieve this on Solaris.
The main one that I see is to introduce a suitably privileged helper daemon
that provides this information via events.
It just so happens nwamd is already monitoring the wifi network status, the
addition of a new event type is probably the best solution to this problem,
and GNOME Netstatus Applet could just listen for these.
This should allow for suitable read-only monitoring of the state of a WiFi
network, providing it supplies enough information to present it to the
user, e.g:
- Device and/or Vanity Name
- Status (connected or not)
- ESSID
- Signal Strength
- Security Type
- Optionally (may be useful to display):
- BSSID
- Speed
Does this sound feasible?
2) The GNOME Panel Presence (which is in the notification area)
This is implemented as an always-running, user daemon which is run at the
start of the session - hence is started with the user's default privileges
at login time.
Functionality that this daemon contains are as follows:
- Handle NWAM daemon events, e.g.
- Show current status information
- Status changes (e.g. network up/down)
- Prompting for a WiFi network selection
Most of the events should be safe enough from the point of view that
it's very limited what can be done and it's all initiated by nwamd,
which is a privileged process and so it is able to act upon any
responses.
- Manual override of NWAM
- Allow the user to override, via a manual selection, the WiFi AP to
use.
- Allow the user to override, via a manual selection, the Network
Environment to use.
- Activate an External Network Modifier (ENM) - e.g. punchin/VPN.
Each of these actions are specifically difficult since they require
the ability to modify the NWAM configuration in SMF and then request a
reload of the settings by NWAM (i.e. a SMF refresh) .
NWAM does have specific authorisations that is supports for it's
configuration:
- solaris.smf.manage.nwam
- solaris.smf.modify.nwam auth
As I understand it, but I could be mistaken about the purpose of each,
a user wanting to have full control from the panel, would be required
to have both of these authorisations to be able to do these actions.
I cannot see us providing all users on the system these authorisations
out-of-the-box, so how to handle the case where the user doesn't have
them is probably the main issue:
- Maybe we could extend these privileges to allow for a more
fine-grained control os
- We could have the UI handle this by now allowing the user to make
such changes if they don't have sufficient privileges - this could
be reflected in the UI with desensitised entries.
- We could provide some mechanism for the user to gain these extra
authorisations, through the use of a Role or Profile - but the
main issue here is that his would need to be done in-process for
it to work without a "helper" application.
- Provide a helper application with the UI that can be used to gain
additional privileges, should the user not have them, by using
libgksu to request a password for a role or root.
- We could look at having NWAM daemon do the work, with libnwam
communicating to it via doors - NWAM can then decided whether to
allow the user to make the change or not. This also provides for
quite a fine-grained level of functionality - e.g. the user could
be permitted to select WiFi networks, but not change the current
Network Environment.
I would really like some advice on how best to achieve what we need.
My main concern is that we maintain the usability that other operating
systems like MacOS/X have achieved in this area since that is what
users tend to demand now.
3) NWAM Properties Application
This is the main configuration application, but since this is a separate
process it is possible to launch it in a way that can be used to gain
extra privileges, should the user not have them - e.g. gksu or similar.
The main issue here is to ensure that we cover all the needed privileges
to be able to both gather status information and also set it.
All settings will be done via libnwam, but the getting of current status
is more likely to be done through direct use of libraries like libdladm,
which in itself requires PRIV_NET_RAWACCESS and PRIV_SYS_NET_CONFIG to
operate (at least according to the dladm sources).
These are pretty serious privileges, and as such it's unlikely to hand
them out to users by default, which I do think is acceptable in this case
since there is an acceptable means to be able to run it if you really want
to.
My main concerns as you will have gathered are with the always running
elements like the GNOME Netstatus Applet and NWAM Panel presence.
I would really appreciate peoples comments on this.
Thanks,
Darren.
