Bug 28604 - /etc/bashrc overwrites the msec umask with less secure defaults
Summary: /etc/bashrc overwrites the msec umask with less secure defaults
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Low enhancement
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-15 20:35 CET by Theodoros Kalamatianos
Modified: 2021-03-16 23:10 CET (History)
3 users (show)

See Also:
Source RPM: bash-5.1-4.1.mga8.src.rpm
CVE:
Status comment:


Attachments

Description Theodoros Kalamatianos 2021-03-15 20:35:40 CET
Description of problem:

The 077 umask set via msec for the "secure" level is not applied consistently. For example:

$ su -
Password: 
# umask
0022                   <---------- This is wrong
# set | grep UMASK
UMASK_ROOT=077         <---------- This is the expected value
UMASK_USER=077
# grep LEVEL /etc/security/msec/security.conf
BASE_LEVEL=secure
# grep UMASK /etc/security/msec/level.secure
WIN_PARTS_UMASK=022
USER_UMASK=077
ROOT_UMASK=077
# su - myuser
$ umask
0002                   <---------- This is also wrong, for a user account

This is caused by this code from /etc/bashrc, which will unconditionally reset the umask when called:


# Even for non-interactive, non-login shells.
if [ "`id -gn`" = "`id -un`" -a `id -u` -gt 99 ]; then
        umask 002
else
        umask 022
fi


A way to deal with this might be to use the symbolic notation, which takes the existing umask into account:

$ umask 022
$ umask og-x
$ umask
0033

So, the code in /etc/bashrc would become:


# Even for non-interactive, non-login shells.
if [ "`id -gn`" = "`id -un`" -a `id -u` -gt 99 ]; then
        umask o-w
else
        umask og-w
fi


Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:
1. set the security level to "secure" (reboot probably required)
2. run `su -`
3. run `umask`
4. the printed umask is not what was set by msec
Comment 1 Aurelien Oudelet 2021-03-15 20:52:01 CET
Hi thanks for reporting this.

Assigning to Mageia Tools Maintainers.

Version: 8 => Cauldron
Whiteboard: (none) => MGA8TOO
Assignee: bugsquad => mageiatools
CC: (none) => luigiwalser, ouaurelien
Priority: Normal => High
Severity: normal => critical

David Walser 2021-03-15 23:50:10 CET

Severity: critical => enhancement
Priority: High => Low
Whiteboard: MGA8TOO => (none)

Comment 2 Theodoros Kalamatianos 2021-03-16 01:36:05 CET
Hmm... I'm reasonably sure that I had picked "normal" as the severity - no idea how it got to "critical". My apologies...
Comment 3 David Walser 2021-03-16 01:55:17 CET
No worries.

It's an interesting issue.  As best I can tell, it's always been this way for our distribution's history.  So it's not critical to change it, but it does seem wrong.

You have /etc/login.defs which sets the default for when it's not overridden by something.

Msec sets the value in /etc/security/shell, which is sourced by /etc/profile.d/01msec.sh.

As you discovered, it then gets overridden by /etc/bashrc, which isn't even mentioned by the bash documentation, so it's not immediately clear how that file is even getting pulled in.

It makes you wonder the history behind it and why it is that way.  Our bash maintainer just quit, so we'll have to see if anyone else knows, and how to best address it.
Comment 4 Dave Hodgins 2021-03-16 03:01:13 CET
(In reply to David Walser from comment #3)
> As you discovered, it then gets overridden by /etc/bashrc, which isn't even
> mentioned by the bash documentation, so it's not immediately clear how that
> file is even getting pulled in.

# cat /etc/skel/.bashrc
# .bashrc

# User specific aliases and functions

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

CC: (none) => davidwhodgins

Comment 5 David Walser 2021-03-16 03:05:24 CET
Ahh, of course.  I glossed right over that.  Thanks Dave.  So, I think the purpose of this umask call in bashrc was for cases where you don't have msec installed.  I think the proper solution, if it's possible, is to only have that code called in that very case.
Comment 6 Theodoros Kalamatianos 2021-03-16 09:32:14 CET
I'd forgotten about login.defs:


# grep MASK /etc/login.defs
UMASK                   077


(Custom file, not sure what the Mageia default is)


I agree that having msec.sh set a sentinel variable would also work. Unlike my suggestion of using the symbolic format, it'd also not override the user intent should someone ever want to allow one of the writable bits.
Comment 7 David Walser 2021-03-16 19:21:56 CET
/etc/profile also has a "umask 022" at the beginning, so instances of it not being set shouldn't happen (the msec part happens at the end of profile).  Even though the if statement in /etc/bashrc is true for my user, I still have a umask of 022 for some reason.  I think bashrc happens last, so that's really weird.

I'm thinking this whole setting umask part in /etc/bashrc is simply unnecessary.
Comment 8 Dave Hodgins 2021-03-16 22:26:59 CET
The scripts in /etc/profile are only executed only at login. The ~/.bashrc file
is processed in all non-login interactive shells such as those started by
konsole or gnome-terminal.

Login to run level 3. The umask command shows 0002. Run "startx startkde" and
open konsole. The umask value is now 0022.
Comment 9 Dave Hodgins 2021-03-16 23:10:03 CET
Also, /etc/login.defs is part of the shadow utils. If it's patched, it's man
page should be modified too. I'm not sure if modifications to the file would be
overwritten by an update. The msec package is not required by basesystem-minimal
so may not be installed.

Setting the umask in /etc/bashrc is one way to ensure it's altered for most
regular users.

Note You need to log in before you can comment on or make changes to this bug.