On Tue, 2008-07-22 at 17:05 -0400, James Carlson wrote:
> Sebastien Roy writes:
> > 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:
>
> I would have expected privileges only on M_{PC,}PROTO and M_IOCTL.
> The others do nothing if you can't get the stream to the state you
> want.
True, that's a valid point.
>
> > DL_ATTACH_REQ net_rawaccess
> > DL_DETACH_REQ net_rawaccess
>
> As mentioned, those should be [none].
>
> > DL_NOTIFY_REQ net_rawaccess
>
> That's an interesting one ... there's at least half an argument to
> make those [none] as well, but with info-req fixed, I think most
> consumers would be happy.
Yeah, I threw that out there, it probably doesn't hurt to allow an
unprivileged process to receive notifications given the current set of
notifications.
> > [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.
>
> Agreed, but you can't get to do M_IOCDATA until you've successfully
> done M_IOCTL, so I'm not sure what the point to that extra message
> check would be.
Yes, true.
> As for Brussles properties, that'd be nice, but it's much easier to
> construct an application that's portable across Solaris versions (and
> potentially to other OSes as well) if you can do a standards-compliant
> DL_ATTACH_REQ and DL_INFO_REQ and look at the results. The only
> difference in versions is whether the user must chmod on the setuid
> bit to get the application to work, and not having to do that would be
> a Solaris security feature.
Good point.
>
> In any event, not this project. ;-}
I know, but it's an interesting and related discussion nevertheless.
-Seb
