Nicolas Williams wrote: > Reply-To set. You do know that the effect was to replace you in the "To" list with security-discuss, while leaving pkg-discuss in the list, right? (At least when I do the polite thing and reply-to-all.)
Reply-To is evil, evil, evil. It's almost never the right answer, and is the wrong answer in most cases where people use it. Grr. Argh. > Well, it's complicated in that we have both approaches. Yes. But which is preferred? If you have a choice of which to implement, which *should* you implement? > Whenever you have services evaluating a caller's authorizations then you > just don't have to "explicitly put on your mask and cape first." There are at least a few cases where a setuid application does something similar. Smpatch is one, though I did the RBAC work there so I can't exactly claim it as precedent. I think there are others. Whether an operation is performed locally by the command or by a service should not factor into the picture, because it is an implementation detail, not part of the user-facing interface of the command. > Yes, that's inconsistent, though hardly fatal. Of course. Inconsistency, however, is bad. We should always to move towards consistency. > W.r.t. to packaging, perhaps user image operations could be done > directly by pkg itself, while ops requiring privilege could be executed > by a local daemon. Then there'd be no need to "explicitly put on your > mask and cape first" in the context of IPS. OTOH, it may complicate the > implementation. (I'm not proposing this, BTW, though it does sound > like a good approach.) Perhaps, but: - Another local daemon? El yucko. - It's not _required_... you can do the same kind of thing with setuid, and with a little care I believe you can do it fairly safely. Side note: how to do pkg setuid fairly safely: Assumptions: 1) Installing files into the system repository is root-equivalent. 2) There are no other operations that require privilege. 3) The RBAC authorization for package operations applies only to the system repository. (Other repositories can use ACLs.) Then: 1) When the command starts, *immediately* check authorizations. (Of course, this must be done very carefully, but it's only a couple of lines of code.) 1a) If you don't have the authorization, drop privileges - set euid to ruid, or whatever. 1b) If you do have the authorization, continue. 2) The rest of the command does not have to be setuid-paranoid. Why not? Because if the user is able to drop files into random places in the file system (like /var/svc/manifest, /etc/rc*.d, or /usr/bin) then there are easier ways to take over the system than trying to break the tool through a buffer overflow attack or whatever. 3) When you get to actually figuring out what operation was requested, check to see if authorization is required, check authorization, and perhaps reject the request.
