Re: The deprecated uid issue: use caps

["D. Boland" <daniel at boland dot nl>]

Hi Linda,

Linda Walsh wrote:
> 
> D. Boland wrote:
> > Linda Walsh wrote:
> >> D. Boland wrote:
> >>> But I had to compromise in some critical areas. One of them is the uid issue.
> >>>
> >>> * sendmail, procmail, mail.local assume that the id of the privileged user is '0'.
> >>>
> >>> Isn't it about time to make this our First Directive also?
> >>>
> >>>
> >> I thought sendmail used capabilities?
> >>
> >> Isn't it about time none of them used a fixed 'uid', but used capabilities?
> >>
> >> I thought hard coding a Uid was going out with the dodo bird?
> >
> > You didn't get the point. We create a kernel on which Linux software runs. We don't
> > dictate how software should be written.
> You are missing the point.
> 
> MS privilege model is the MS version of the linux capability model.
> 
> MS didn't get it wrong, linux has been slow to adopt, but MS had linux
> capabilities 10 years before linux did.
> 
> Several other people have tried to explain that the way to go is to use
> the "minimum priviledge model".
> 
> For example, almost ALL user have the "unreadable directory traversal"
> priv/capability.
> 
> To enforce it cost alot in execution time on Windows (as it would under
> cygwin).
> 
> Another priviledge is to "impersonate" another user; sendmail would
> likely need such a privilege.  Another is to ignore file-permissions.
> It would be questionable whether or not sendmail needed that.
> 
> Sendmail was using capabilities back in 2000 when I brought a basic
> "non-reciprocal action"  bug in the capability code to the attention
> of Ted Tso, he told me and others that I didn't know what I was talking
> about and they were following POSIX and my "find" was irrelevant under
> POSIX.
> About 10 days later there was a day-zero exploit involving the bug
> in the defective code using sendmail's capability usage as the vector.
> The result was kernel caps being disabled for the next few years until
> the cap-code could be reviewed by more eyes and knew what to look for.
> 
> So I'm pretty sure sendmail has had code to extensively run solely off
> of capabilities and has had it for some time.  I'd be surprised if it
> was removed.
> 
> Linux software that uses the capability model is likely to not have
> these problems.  But saying that any random linux software with security
> bugs
> from the past should work on cygwin, seems like a ridiculous stance to
> take.
> 
> You can set capabilities on files processes and network sockets. Linux file
> systems with "extended attributes" or "alternate data forks" (2 names
> for the
> same thing), can and do support "SETCAP" on linux files that works just
> like SETUID, but for capabilities.
> 
> MS only supports the capability model and uses it to implement their
> Admin or privileged user model.  They don't support the less secure setuid
> model that linux is moving away from.
> 
> Does this help clarify the issue ?

Thanks for disagreeing. You are completely right. Sendmail seems to demand a much
more restrictive impersonation policy than Windows offers. That's why I can't get
the thing to work. It constantly tests if certain actions are allowed and if so, it
just refuses to deliver e-mail.

I'll look into this capabilities thing, but I do not intend to change anything
significant  in the Sendmail code. Maybe the folks at Proofpoint will switch to it
one day. 

Daniel


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple