Quick update: a bunch of days ago I udated my debian installation, screwing up my grsec setup.
First thing I did, was creating a copy of my current pax flags via::
$ find /usr -type f -exec getfattr -d {} \;
This was a superset of the files listed in /etc/paxctld.conf because
(as far as I could tell[*]) paxctld updates only the flags of the files
listed.
Then I tried to trace down the issue.
I looked at dmesg, but there were no significant messages.
I enabled debugging for gdm3[**] and looked at the tracebacks on
/var/log/daemon.log. The relevant lines were:
systemd[1]: Started Session 7 of user maker.
gnome-session-binary: DEBUG(+): GsmSystemd: received logind signal:
SessionNew
gnome-session-binary: DEBUG(+): GsmSystemd: ignoring SessionNew signal
gnome-session-binary: WARNING: Could not get session id for session.
Check that logind is properly
installed and pam_systemd is getting used
at login.
gnome-session-binary: WARNING: App 'org.gnome.Shell.desktop' exited with
code 1
console-kit-daemon: GLib-CRITICAL: Source ID 127 was not found when
attempting to remove it
I got curious at the org.gnome.Shell.desktop warning, and given that it
wasn't possible[***] to start gnome-session by itself, I replaced the
line:
Exec=/usr/bin/gnome-shell
with something like:
Exec=/usr/bin/bash -c 'strace -f /usr/bin/gnome-shell 2> /tmp/dump'
in file /usr/share/applications/org.gnome.Shell.desktop.
After attempting to log-in, the screen would become black for a few
seconds, then go back to gdm3.
Examining strace's output, I realized that gnome-shell attempts to read
/proc/1/cgroup, which is not visible from my user (maker) nor Debian-gdm
under a linux-*-grsec kernel (not sure what's exactly the option name
for hiding /proc/ processes not owned by the user).
So I run `gpasswd -a Debian-gdm grsec-proc` and I was finally able to
see "GNOME on Wayland" among the available sessions listed, but not yet
able to successfully start a gnome-session with "maker".
I run `gpasswd -a maker grsec-proc` and finally, I was able to log-in on
GNOME on Wayland.
At this point, I started minimizing my /etc/paxctld.conf.
For every gnome-related executable, I attempted to comment it, run
$ setfattr -x user.pax.flags executable
and then re-log-in.
On the way I got errors like:
grsec: denied RWX mmap of <anonymous mapping> by
/usr/bin/gnome-shell[gnome-shell:3670] uid/euid:1000/1000
gid/egid:1000/1000, parent
/usr/lib/gnome-session/gnome-session-binary[gnome-session-b:3636]
suid/euid:1000/1000 gid/egid:1000/1000 grsec: denied RWX mmap of
<anonymous mapping> by
/usr/lib/gnome-terminal/gnome-terminal-server[gnome-terminal-:2846]
uid/euid:1000/1000 gid/egid:1000/1000, parent
[ 153.707695] grsec: denied RWX mmap of <anonymous mapping> by
/usr/bin/pulseaudio[alsa-sink-ALC32:2578] uid/euid:1000/1000
gid/egid:1000/1000, parent /usr/lib/systemd/systemd[systemd:1]
uid/euid:0/0 gid/egid:0/0
(For the latter I had to play an audio file)
The above told me which executables really required me to relax memory
protection. The resulting paxctld.conf is attached.
In the process, I also got some errors like:
grsec: denied kernel module auto-load of fuse by uid 1000
grsec: denied resource overstep by requesting 2048 for RLIMIT_NOFILE
against limit 1024 for /usr/bin/Xwayland[Xwayland:2558]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/usr/bin/gnome-shell[gnome-shell:2546] uid/euid:1000/1000
gid/egid:1000/1000
grsec: denied resource overstep by requesting 2048 for RLIMIT_NOFILE
against limit 1024 for /usr/bin/Xwayland[Xwayland:2558]
uid/euid:1000/1000 gid/egid:1000/1000, parent
/usr/bin/gnome-shell[gnome-shell:2546] uid/euid:1000/1000
gid/egid:1000/1000
Similar errors appears for the executable /usr/bin/Xorg when I run GNOME
on X. I'm not sure why these programs are requesting to be able to open
2048 file descriptors, but since this warnings don't seem to really
break anything important I'm just going to ignore them and call it a
day.
Wrapping up, I am asking:
1. to add the following lines to /etc/paxctld.conf:
# gnome
/usr/lib/gnome-terminal/gnome-terminal-server m
/usr/bin/gnome-shell m
/usr/bin/pulseaudio m
The above grsec tracebacks indicate that these are for sure needed,
plus it seems to be coherent with what's been said in the past::
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090>.
and to be a subset of the ones maintained by the SubgraphOS people::
<https://github.com/subgraph/paxrat/blob/master/paxrat.conf>
Sadly, I don't really know how to show, just from the source code of
a package, to statically infer if it's harmful to apply memory
protection or layout randomization.
I guess until somebody is able to do that, these sort of
configurations, not really equal to each other, will keep spreading.
2. to add Debian-gdm, plus all users that could potentially run a
window manager, to the group grsec-proc - maybe asking upsteam if
they really really need to open /proc/1/?
3. to replace
/usr/lib/chromium-browser/chromium-browser m
with
/usr/lib/chromium/chromium m
0. to please test what I did.
[*]
By «updated only the listed flags» I mean the following::
$ getfattr -d /usr/lib/chromium/chromium
getfattr: Removing leading '/' from absolute path names
# file: usr/lib/chromium/chromium
user.pax.flags="em"
$ cat /etc/paxctld.conf | grep chromium
# chromium
/usr/lib/chromium/chromium m
Now if I comment this line, the pax flags stay there::
$ sudo sed 's,/usr/lib/chromium,#/usr/lib/chromium,' -i /etc/paxctld.conf
$ sudo service paxctld restart
$ cat /etc/paxctld.conf | grep chromium
# chromium
#/usr/lib/chromium/chromium m
$ getfattr -d /usr/lib/chromium/chromium
getfattr: Removing leading '/' from absolute path names
# file: usr/lib/chromium/chromium
user.pax.flags="em"
By the way there's another bug in the shipped paxctld.conf:
it's been a while (/usr/lib/)chromium-browser has been renamed
(/usr/lib/)chromium.
[**]
In /etc/gdm3/daemon.conf I added::
[debug]
Enable=true
[***]
gnome-session as far as I understood is fired by dbus. I got weird
behavious when trying to fire manually gnome-session or gdm3.
For example, if you run /usr/lib/gdm3/gdm-x-session without arguments it
segfaults (lol?), and using gdb on the debug version of gdm it seems it
comes from here:
if (args == NULL || args[0] == NULL || args[1] != NULL) {
g_warning ("gdm-x-session takes one argument (the session)");
exit_status = EX_USAGE;
goto out;
}
paxctld.conf
Description: Binary data
-- µ.
