? 2008?11?14? 15:40, Yifan Xu ??: > Kacheong Poon wrote: >> Yifan Xu wrote: >> >> >>> This scheme should work without requiring vrrpd to run as >>> root. But there are some limitations. It implies that only >>> services that run as a daemon could utilize the notification. >>> For example, if an administrator wanted to enable forwarding >>> only when the VRRP turns into master state, an executable is >>> required to do "svcadm enable/disable ipv4-forwarding" or >>> "ndd -set /dev/ip ip_forwarding 1/0". >> >> Have you checked out RBAC and see if it can help here? >> BTW, vrrpd should already have enough network configuration >> privileges. Is it safe to assume that these privileges are >> enough for all network configuration related services which >> may make use of VRRP? Then the executable does not need >> to run by root and have all privileges. > > That question is actually the concern. Can we assume network > configuration privileges are sufficient for reasonable actions to > be registered? If not, what else privileges should be added to > vrrpd? As you can see I didn't get to find a better example than > the forwarding knob, which still falls in the networking privilege > set. > > But there is another issue for not using root. Users who has > insufficient networking privileges are still able to put executables > in /etc/vrrpd/ to be executed by vrrpd.
The simple solution to this issue is to ask the user to explicitly "enable_hook" with vrrpd; when vrrpd receives an "enable_hook" request, it check if the requesting process has certain privileges. (So we'll add two more sub-cmd to vrrpadm: enable_hook, disable_hook) Thus a related issue: what if a non-privileged user modifies the hook executable after a privileged user "enables_hook"? The solution is that, the requester owns the file under /etc/vrrpd/ (but /etc/vrrpd/ is owned by the user "vrrp"), and is responsible for assigning proper permissions to the file so that others cannot modify it. When the state transition occurs, vrrpd runs the executable only if its owner is the requester. If not, vrrpd may report an error or alarm. >>> Another requirement >>> for this scheme is the services should be aware of the >>> notification interface and make some changes to exploit it. >> >> I don't understand. Who will provide the notification >> executable? I think the service developer who wants to >> make use of this mechanism will provide it. And I think >> the developer will need to know about this interface in >> order to use it. What is the extra requirement? > > It is not an issue for future services who want to exploit > vrrp notification. What I mean is such an interface would > disable existing service/program from being utilized > without any modification, if the vrrpd only provide an > IPC notification scheme. >> >> >>> To make it flexible and easy to use we prefer the simple >>> solution of raising the security threshold to allow all kinds >>> of actions, because privileges required for various executions >>> are unpredictable. Opinions? >>> >> >> >> So this is the traditional all-or-nothing security model. >> I think Solaris has moved beyond this for quite some time. >> I suspect that you need stronger justification to go back >> in time for new service. >> > Understood. I think we need to chew on it a bit more. Right; we need to understand more about the new model. > > Yifan > > > ------------------------------------------------------------------------ > > _______________________________________________ > networking-discuss mailing list > [email protected] _______________________________________________ networking-discuss mailing list [email protected]
