This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: The deprecated uid issue: use caps
- From: "D. Boland" <daniel at boland dot nl>
- To: cygwin at cygwin dot com
- Date: Sat, 26 Jul 2014 15:33:51 +0200
- Subject: Re: The deprecated uid issue: use caps
- Authentication-results: sourceware.org; auth=none
- References: <53CF6CEC dot 6D68E485 at boland dot nl> <53CF7012 dot 2070608 at tlinx dot org> <53CF749A dot 1315B799 at boland dot nl> <53D30D67 dot 2070209 at tlinx dot org>
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