Hi Paul
Thank you for pointing out the reason why umask 0 is used. I think it is reasonable.
I think it would be a good thing if the caller could tell the umask to use,
or alternatively use different functions.
But I let other people handle that.
Your explanation shows that the vulnerability is in pcs only and the
generic code is not vulnerable since the intention was not to use it for internal communication without further authentication or similar.
Cheers
// Ola
On Sat, 10 Sept 2022 at 03:36, Paul Wise <
pabs@debian.org> wrote:
On Fri, 2022-09-09 at 22:41 +0200, Ola Lundqvist wrote:
I see that I was not clear what I meant with "in general" :-)
Woops, sorry for the noise :)
Here I found how the generic source code looks like:
https://rubydoc.info/gems/thin/1.3.1/Thin%2FBackends%2FUnixServer:connect
You can see the umask(0) there.
That is what I think is insecure, not pcs itself.
Agreed.
But I think Thin::Backends::UnixServer#connect is still insecure.
It looks like the issue was introduced in this pull request:
https://github.com/macournoyer/thin/pull/28
It sounds like unicorn might have the same issue as thin.
Looking at the unicorn code, it sets the default umask to 0
when the umask option is not set, so not quite as bad but still.
The justification for the default umask of 0 in unicorn is:
# Typically UNIX domain sockets are created with more liberal
# file permissions than the rest of the application. By default,
# we create UNIX domain sockets to be readable and writable by
# all local users to give them the same accessibility as
# locally-bound TCP listeners.
So the choice of umask 0 is deliberate in unicorn and the thin folks
copied that choice and dropped the possibility of overriding it,
since they did't have an options argument for the function.
Since UNIX domain sockets are often used for situations that are not
like localhost TCP sockets, that was probably the wrong choice, but
the unicorn/thin folks are likely from the web developer community,
which is mostly focused on HTTP and TCP and often use localhost for development, so it was the right choice within their bubble.
I feel like the APIs of both thin and unicorn need redesigning so that
the choice of umask to use must be made by the caller. Then the web
developer community can use 0 and others will choose a safe value.
Really the web developer community shouldn't use 0 either but I expect
that convincing them of that might not be possible.
I'm not sure how palatable the API change will be to thin/unicorn.
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
--- Inguza Technology AB --- MSc in Information Technology ----
|
ola@inguza.com opal@debian.org |
|
http://inguza.com/ Mobile: +46 (0)70-332 1551 |
---------------------------------------------------------------
<div dir="ltr">Hi Paul<div><br></div><div>Thank you for pointing out the reason why umask 0 is used. I think it is reasonable.</div><div>I think it would be a good thing if the caller could tell the umask to use, or alternatively use different functions.<
/div><div>But I let other people handle that.</div><div><br></div><div>Your explanation shows that the vulnerability is in pcs only and the generic code is not vulnerable since the intention was not to use it for internal communication without further
authentication or similar.</div><div><br></div><div>Cheers</div><div><br></div><div>// Ola</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 10 Sept 2022 at 03:36, Paul Wise <<a href="mailto:
pabs@debian.org">pabs@debian.
org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2022-09-09 at 22:41 +0200, Ola Lundqvist wrote:<br>
> I see that I was not clear what I meant with "in general" :-)<br>
Woops, sorry for the noise :)<br>
> Here I found how the generic source code looks like:<br>
> <a href="
https://rubydoc.info/gems/thin/1.3.1/Thin%2FBackends%2FUnixServer:connect" rel="noreferrer" target="_blank">
https://rubydoc.info/gems/thin/1.3.1/Thin%2FBackends%2FUnixServer:connect</a><br>
> <br>
> You can see the umask(0) there.<br>
> <br>
> That is what I think is insecure, not pcs itself.<br>
Agreed.<br>
> But I think Thin::Backends::UnixServer#connect is still insecure.<br>
It looks like the issue was introduced in this pull request:<br>
<a href="
https://github.com/macournoyer/thin/pull/28" rel="noreferrer" target="_blank">
https://github.com/macournoyer/thin/pull/28</a><br>
It sounds like unicorn might have the same issue as thin.<br>
Looking at the unicorn code, it sets the default umask to 0<br>
when the umask option is not set, so not quite as bad but still.<br>
The justification for the default umask of 0 in unicorn is:<br>
# Typically UNIX domain sockets are created with more liberal<br>
# file permissions than the rest of the application. By default,<br> # we create UNIX domain sockets to be readable and writable by<br> # all local users to give them the same accessibility as<br>
# locally-bound TCP listeners.<br>
So the choice of umask 0 is deliberate in unicorn and the thin folks<br>
copied that choice and dropped the possibility of overriding it,<br>
since they did't have an options argument for the function.<br>
Since UNIX domain sockets are often used for situations that are not<br>
like localhost TCP sockets, that was probably the wrong choice, but<br>
the unicorn/thin folks are likely from the web developer community,<br>
which is mostly focused on HTTP and TCP and often use localhost for<br> development, so it was the right choice within their bubble.<br>
I feel like the APIs of both thin and unicorn need redesigning so that<br>
the choice of umask to use must be made by the caller. Then the web<br> developer community can use 0 and others will choose a safe value.<br>
Really the web developer community shouldn't use 0 either but I expect<br> that convincing them of that might not be possible.<br>
I'm not sure how palatable the API change will be to thin/unicorn.<br>
-- <br>
bye,<br>
pabs<br>
<a href="
https://wiki.debian.org/PaulWise" rel="noreferrer" target="_blank">
https://wiki.debian.org/PaulWise</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><div><font face="courier new, monospace" size="1"> --- Inguza Technology AB --- MSc in Information
Technology ----</font></div><div><font face="courier new, monospace" size="1">| </font><a href="mailto:
ola@inguza.com" style="font-family:"courier new",monospace;font-size:x-small" target="_blank">
ola@inguza.com</a><span style="font-family:&
quot;courier new",monospace;font-size:x-small"> </span><a href="mailto:
opal@debian.org" style="font-family:"courier new",monospace;font-size:x-small" target="_blank">
opal@debian.org</a><span style="font-family:
"courier new",monospace;font-size:x-small"> |</span></div><div><font face="courier new, monospace" size="1">| <a href="
http://inguza.com/" target="_blank">
http://inguza.com/</a> Mobile: +46 (0)70-332
1551 |</font></div><div><font face="courier new, monospace" size="1"> ---------------------------------------------------------------</font></div></div><div><br></div></div></div></div></div></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)