Artem Kachitchkine wrote: > Sebastien Roy wrote: >> In adding per-ioctl privilege checks in dld, I ran into an interesting >> problem. I thought that requiring PRIV_SYS_NET_CONFIG for >> DLDIOC_DOORSERVER would be sufficiently safe, but unfortunately dlmgmtd >> itself (the only thing which uses the ioctl) doesn't even have that >> privilege when it issues that ioctl. The ioctl is issued after >> privileges have been dropped and it has changed its uid to dladm. >> >> The question now becomes how to secure DLDIOC_DOORSERVER. Should I keep >> the PRIV_SYS_NET_CONFIG requirement and yank the code in dlmgmtd that >> creates the door file and calls DLDIOC_DOORSERVER up to before privileges >> are dropped, or relax the privilege checks in the kernel to just check to >> see if the user-id is dladm? Any other ideas? > > FWIW my Brussels persistence changes add PRIV_SYS_NET_CONFIG to dlmgmtd, > to be able to interact with dld (open control dev and issue > DLDIOCSETPROP). Clearview PSARC materials actually list this privilege > for dlmgmtd, though the code does not match.
dlmgmtd does start with PRIV_SYS_NET_CONFIG (it starts with all privileges). It opens the dld control node with that privilege, then drops all privileges (see dlmgmt_init_privileges()). In the updated iptun code, any random Joe can open the dld control device. Each ioctl will have its own set of required privileges, so that unprivileged users can do sane things like type "dladm show-link". DLDIOCSETPROP is clearly one that should require PRIV_SYS_NET_CONFIG. Are you saying that dlmgmtd will retain PRIV_SYS_NET_CONFIG even after having dropped privileges? -Seb
