Bug 1170169 - AUDIT-FIND: enlightenment: enlightenment_system: /etc/enlightenment/sysactions.conf limitations are ineffective
AUDIT-FIND: enlightenment: enlightenment_system: /etc/enlightenment/sysaction...
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Simon Lees
E-mail List
Depends on:
Blocks: 1169238
  Show dependency treegraph
Reported: 2020-04-22 09:38 UTC by Matthias Gerstner
Modified: 2020-05-22 09:29 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Our system.conf (2.92 KB, text/plain)
2020-05-19 07:03 UTC, Simon Lees

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2020-04-22 09:38:19 UTC
+++ This bug was initially created as a clone of Bug #1169238

f) /etc/enlightenment/sysactions.conf limitations are ineffective

There is a security mechanism implemented based on the file
/etc/enlightenment/sysactions.conf. This file defines which users/groups
are allowed to execute the `enlightenment_system` binary in the first place.

The `_etc_enlightenment_system_conf()` function parses this file. However
there seems to be a while or for loop body missing. Instead only the first
line of the file is ever parsed, which happens to be a comment line by
default. The logic in the function defaults to "allow everything" if nothing
else was determined. Thus this security mechanism is currently ineffective
and all users in the system can use the full functionality of the setuid-root

I suggest to deny access by default and correct the algorithm to correctly
parse the configuration file.
Comment 1 Simon Lees 2020-04-22 11:05:37 UTC
Upstream: https://phab.enlightenment.org/T8675
Comment 2 Matthias Gerstner 2020-04-30 12:37:05 UTC
The upstream commit fixes the main issue: the missing loop body.

The question about the default behaviour remains open but should be
non-critical for security, hopefully.
Comment 3 Simon Lees 2020-05-01 02:23:21 UTC
In terms of an openSUSE config it is likely we will ship with the "Power" section (shutdown, reboot etc) disabled because on openSUSE we use systemd. 

The other parts will be enabled, but only for users in the "users" group. Atleast that is my plan for the moment, I need to take the time to write and test that config file though.
Comment 4 Simon Lees 2020-05-19 07:03:53 UTC
Created attachment 837955 [details]
Our system.conf
Comment 5 Simon Lees 2020-05-19 07:04:52 UTC
Our current config is attached, it only allows users in the "users" group and disables the power and storage subsystems because they are not needed in our case.
Comment 6 Matthias Gerstner 2020-05-19 09:10:22 UTC
Thank you for sharing the config file. It looks good to me.
Comment 7 Matthias Gerstner 2020-05-22 09:27:29 UTC
I'm still not totally happy with the "allow by default" semantics of the
system.conf file. As is stated in the configuration file comment:

Any user or group NOT matched by an allow or a deny will be ALLOWED to
perform the action by default

This is usually a bad idea. We do have the "user: * deny: *" line at the end
of the configuration file. But if either an administrator mistypes something
in the configuration file, or the file processing logic is messed up again in
the code, we might open up the tool to more users than intended.
Comment 8 Matthias Gerstner 2020-05-22 09:29:37 UTC
The individual finding is fixed in any case. The configuration file is now
effective. Therefore I'm closing the bug.