Bug 49219 - make all python scripts in PAM stack optional
make all python scripts in PAM stack optional
Status: NEW
Product: UCS
Classification: Unclassified
Component: PAM
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks: 49060
  Show dependency treegraph
 
Reported: 2019-04-02 13:49 CEST by Daniel Tröder
Modified: 2019-05-13 09:40 CEST (History)
5 users (show)

See Also:
What kind of report is it?: Security Issue
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Error handling, Troubleshooting, Workaround is available
Max CVSS v3 score: 4.1 (CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Tröder univentionstaff 2019-04-02 13:49:26 CEST
During the work on Bug #49060 it was discovered, that if an ImportError occurs in a Python script, the PAM stack will interpret it as "no access allowed". If is is a "required" directive in /etc/pam.d/common-session, it will lead to a non-accessible system.

The Python3 migration raises the dangers of such exceptions, so marking all Python scripts in the PAM stack as "optional" instead of "required" raises the robustness of the system.
Comment 1 Florian Best univentionstaff 2019-04-02 13:54:39 CEST
Most pam scripts are already optional. The one which is by default required currently is univention-mount-homedir.

Workaround currently is:
ucr set homedir/mount/required=false
Comment 2 Arvid Requate univentionstaff 2019-04-02 16:15:40 CEST
IMHO the scripts that we deliver to the customer should be free of "ImportError" exceptions or anything like that. You can always break the system from within, we need to make sure that it works well by default.
Comment 3 Daniel Tröder univentionstaff 2019-04-02 16:48:19 CEST
We should also lower the risk posed by non-default situations (like interrupted updates) by making the system as resilient as possible.
Comment 4 Florian Best univentionstaff 2019-04-02 16:57:59 CEST
(In reply to Daniel Tröder from comment #3)
> We should also lower the risk posed by non-default situations (like
> interrupted updates) by making the system as resilient as possible.
But it might be better to be more transparent in this situation?
If this really fails there is a deeper error.
If we ignore this, the functionality of e.g. univention-mount-homedir is not executed and nobody notices it until the log files are scanned.

The other view is ofc. that if there are issues in the scripts which can be triggered by regular users, then DoS is possible. That's why you flagged it as security issue?
Comment 5 Daniel Tröder univentionstaff 2019-04-02 17:40:01 CEST
(In reply to Florian Best from comment #4)
> (In reply to Daniel Tröder from comment #3)
> > We should also lower the risk posed by non-default situations (like
> > interrupted updates) by making the system as resilient as possible.
> But it might be better to be more transparent in this situation?
> If this really fails there is a deeper error.
> If we ignore this, the functionality of e.g. univention-mount-homedir is not
> executed and nobody notices it until the log files are scanned.
That is why I had added a "syslog()" line to the ImportError handling.
Maybe we could do that again, but after logging, reraise it? This way the problem would not be hidden, and it would be logged.

> The other view is ofc. that if there are issues in the scripts which can be
> triggered by regular users, then DoS is possible. That's why you flagged it
> as security issue?
I was merely thinking about "reliability" as one of the dimensions of "security".

The incident would in this case (that actually happend during the work on Bug #49060) not be triggered by a common user, but by an incomplete update started by an administrator.