#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
Component: | android → platforms |
---|---|
Priority: | major → critical |
Status: | new → assigned |
comment:2 Changed 3 years ago by
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.
comment:3 Changed 3 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Not heard back, closing.
comment:4 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1635
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.