Context Navigation

← Previous Ticket
Next Ticket →

#1635 closed defect (worksforme)

insecure umask 0000 on ubuntu server

Reported by:	mattja	Owned by:	mattja
Priority:	minor	Milestone:	2.2
Component:	platforms	Version:	trunk
Keywords:	security	Cc:

Description

xterm started on the remote server (via winswitch) runs with umask 0000.
This has security impact as files/directories created by users are then world-writable.
Expected: some sensible default like 002 or 022.

Version: winswitch 0.12.23-1, xpra 2.1.1-r16658-1
Possible cause: winswitch server assumes umask will be set in /etc/bashrc.
That is true on Red Hat derived systems.
But it is not true on Ubuntu (tested 16.04 LTS) where I think umask is expected to be set by PAM session (pam_umask.so).

Perhaps related, the PAM file provided by /etc/pam.d/xpra
seems to assume a Red Hat style system and most of the PAM modules referenced there do not exist on a Ubuntu system.

Change History (4)

comment:1 Changed 3 years ago by Antoine Martin

Component:	android → platforms
Priority:	major → critical
Status:	new → assigned

Ouch.
The pam file is only used when we start sessions via the system wide proxy.
I assume that the umask is correctly set if we start sessions with --start-via-proxy=no?
Best way to fix this is to figure out the correct contents for /etc/pam.d/xpra for all Debian / Ubuntu distributions. Oh, that's going to be fun seeing the complete lack of any clear documentation on the subject.

comment:2 Changed 3 years ago by Antoine Martin

Owner:	changed from Antoine Martin to mattja
Priority:	critical → minor
Status:	assigned → new

Just tested on a bunch of Debian distros:

Debian 9 Stretch: default umask is set to 0022, also correctly set in the xpra session
Debian 8 Jessie: same as above
Ubuntu 17.04: same as above
Ubuntu 16.04: umask is 0002, but 0022 within the xpra session - which is more strict!

So, although the umask is different, it isn't set to 0000 and is in fact more strict.
The pam_umask module is yet another Ubuntu-only thing.
I've tried removing system-auth from the /etc/pam.d/xpra file and adding:

@include common-account
@include common-session
@include common-password

The pam open code succeeds but the umask is unchanged after the call. (common session includes: session optional pam_umask.so)

And... that's all I've got time for. It doesn't look like a big problem anyway since the umask is stricter.
Hopefully someone who understands what Ubuntu is doing in this area can fix this.

Last edited 3 years ago by Antoine Martin (previous) (diff)