[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Vulnerability in pcs or is it in more generic code?



Hi Paul

I see that I was not clear what I meant with "in general" :-)

In the fix for pcs
https://github.com/ClusterLabs/pcs/commit/de068e2066e377d1cc77edf25aed0198e4c77f7b
you can see a comment that there is a change from umask(0) to umask(0x077)

It was this umask(0) (in Thin::Backends::UnixServer#connect) I was referring to as "in general".

I mean the fix is to override this more generic function that is obviously not secure enough.

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.

It looks like pcs code was not vulnerable because what I missed to check was whether this source code was present in buster. It was not as someone have concluded.

But I think Thin::Backends::UnixServer#connect is still insecure.

Cheers

// Ola

On Tue, 6 Sept 2022 at 03:09, Paul Wise <pabs@debian.org> wrote:
On Mon, 2022-09-05 at 21:38 +0200, Ola Lundqvist wrote:

> I agree that it is good to fix the pcs package, but shouldn't we fix
> the default umask in general?
> I would argue that the default umask is insecure.

bookworm login sets new user home directories to secure permissions:

   $ grep -E 'HOME_MODE\s*[0-9]' /etc/login.defs
   #HOME_MODE   0700

This somewhat mitigates, but not completely, the umask being insecure:

   $ grep -E 'UMASK\s*[0-9]' /etc/login.defs
   UMASK                022

I can't find any bugs open about changing the default umask,
but it was mentioned in replies to the recent adduser thread:

https://lists.debian.org/msgid-search/YieJALY0ny0+07pw@torres.zugschlus.de

--
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 |
 ---------------------------------------------------------------


Reply to: