On Tue, 2008-07-22 at 15:54 -0400, James Carlson wrote:
> Sebastien Roy writes:
> >   This case does propose to relax the requirement for WiFi ioctls from
> >   sys_net_config to the new sys_dl_config privilege in order to be
> >   in-line with other GLDv3 datalink administration ioctls.  The
> >   net_rawaccess privilege will still be required for WiFi operations,
> >   however, since libdladm.so still has to open /dev/net DLPI nodes in
> >   order to issue WiFi ioctls.
> 
> This all looks good.  One note: the excess privilege needed to open
> DLPI nodes affects other things as well.  There are applications that
> would like to read out the interface MAC addresses but currently
> cannot do so because it requires privilege.  It's not part of this
> project, but we probably have to address that one-privilege-for-all-
> access scheme for DLPI at some point in the future.

Yes, I agree, and I did some thinking about this while trying to solve
the WiFi problem.  One half-baked scheme that came to mind was to relax
the privileges required to open /dev/net DLPI nodes to the empty
privilege set, and instead implement a per-STREAMS-message-type
privilege scheme in dld's dld_wput() function.  Something like:

M_DATA          net_rawaccess
M_PROTO         [1]
M_PCPROTO       [1]
M_FLUSH         net_rawaccess
M_IOCTL         [2]
M_IOCDATA       [2]

[1] This would depend on the individual DLPI primitive.  Here's a
proposed breakdown:

DL_INFO_REQ             [none]
DL_BIND_REQ             net_rawaccess
DL_UNBIND_REQ           net_rawaccess
DL_UDQOS_REQ            net_rawaccess
DL_ATTACH_REQ           net_rawaccess
DL_DETACH_REQ           net_rawaccess
DL_ENABMULTI_REQ        net_rawaccess
DL_DISABMULTI_REQ       net_rawaccess
DL_PROMISCON_REQ        net_rawaccess
DL_PROMISCOFF_REQ       net_rawaccess
DL_PHYS_ADDR_REQ        [none]
DL_SET_PHYS_ADDR_REQ    net_rawaccess (or perhaps sys_dl_config?)
DL_NOTIFY_REQ           net_rawaccess
DL_CAPABILITY_REQ       net_rawaccess
DL_PASSIVE_REQ          net_rawaccess

[2] The dld module would pass private driver ioctls down via mc_ioctl()
without checking for privileges, and drivers would then be responsible
for implementing their own per-ioctl privilege checks.  I haven't looked
at enough drivers closely to see how much work it would be to push down
privilege checks down to that level.  If this part is too disruptive a
change, then requiring net_rawaccess for M_IOCTL and M_IOCDATA wouldn't
be a show-stopping compromise IMO.

-Seb



Reply via email to