Grsecurity on the Desktop

[mprotect]

Hello everyone. I have installed grsecurity on my desktop via a hardened Gentoo installation. Everything seems to be working perfectly, barring a few minor issues, some of which I have already fixed myself, thanks to TFM. I do have some questions to toss out for those with more knowledge than I.

1. I notice I can not su to root for sys admin tasks. Is this normal? (I've actually two hardened setups with grsecurity and didn't put my user account in the wheel group on the second installation for this reason.) If users can't su to root, that won't turn me away from this. I can see where it would increase security, so am ok with it.

2. From reading the fine manual, I learned that in cases where apps misbehave, it can usually be fixed by 'paxctl -m /path/to/binary'. That's exactly what I did with mplayer, in order to view movies and it worked like a charm. Is that also the 'cure' for apps that are stack smashed? As an example, pcmanfm gets stack-smashed, although this is not a grsecurity error. There's actually already a bug filed against libfm, which pcmanfm relies on. It looks like that lib is responsible for the stack-smash. Would 'paxctl -m pcmanfm' stop the stack smash or would I need to paxctl libfm, or does paxctl have no control of the stack smash at all? It's no issue if I can't use pcmanfm, because rox doesn't have this issue.

3. Does grsecurity restrict automounting? Although I ran Gentoo for 5 years previously, I haven't messed with it for the last couple of years, so I am not sure if I need to setup automounting or if gresecurity restricts it. I really only need automounting for two purposes - burning the occasional CD, and most importantly, mounting flash drives for Gnucash backups.

4. I haven't run gradmin or gradmn or whatever the program is that you run in learning mode to create the policies. I figured it was best to get the above issues corrected first before I stepped there.

Oh and THANK YOU SO MUCH to the developers of Grsecurity. I don't claim to understand how it works and I don't write code, but these ideas seem brilliant to me and particularly the additional layers of permissions on top of the typical Unix rwx permissions. I am not sure that I even need grsecurity in my present situation, but my curiosity in it has got me absolutely HOOKED!

And as far as my installs, I used a vanilla stage3 tarball from a chroot, synced, switched to the hardened profile, rebuilt the toolchain twice, rebuilt the system, then built the world. The checksec.sh script referenced elsewhere in these forums confirms everything is in order in the kernel, binaries and running processes.

[spender]

Hi there,

1) Grsecurity certainly doesn't aim to prevent this. Are you talking about some GUI-based su or the one from the command-line? I can see a GUI-based one "failing" due to improper PT_GNU_STACK markings on some library, but we've never seen a report of the commandline su failing. I'd need to see some error logs here.

2) I'd need to see error logs for this as well. paxctl though should only be used on main executables, not on libraries, as it has no effect on libraries.

3) It may, when GRKERNSEC_MODHARDEN is enabled. It's unfortunately necessary due to a userland vulnerability in udisks that by default allows filesystems of any type to be loaded by a non-root user (prior to some additional security features in grsecurity, this udisks vulnerability allowed any installed kernel module to be loaded by a non-root user). If you compile in support for the filesystems needed by any auto-mounted device, or load the modules specifically in an init script, grsecurity shouldn't affect automounting at all.

4) gradm is the utility for that.

-Brad

[mprotect]

Grsecurity certainly doesn't aim to prevent this.

That was my mistake. I logged into the first hardened gentoo system and checked /etc/group. I never did make my user part of the wheel group, although I thought I did. I double checked it on this system by adding myself to wheel and can su now.

Are you talking about some GUI-based su or the one from the command-line? I can see a GUI-based one "failing" due to improper PT_GNU_STACK markings on some library, but we've never seen a report of the commandline su failing. .

The gui su apps work too, at least gksu does since I added myself to wheel. I just tested it to be sure.

I'd need to see error logs for this as well.

Ok. I have logs from two different systems, but also from two different apps. I had forgotten about an issue with gmrun until I looked at the logs in the old system. The old system was compiled with gcc 4.4.5. The new system is compiled with gcc 4.5.3, (well most of it. GCC was upgraded yesterday, but I've only rebuilt system, not world) if that makes any difference.

The old system log entries:

PCMANFM:
Sep 6 21:33:35 localhost pcmanfm: stack smashing attack in function <unknown> - terminated
Sep 6 21:33:35 localhost Report to http://bugs.gentoo.org/

GMRUN:
Sep 6 21:33:47 localhost klogd: [ 2169.522525] gmrun[15255]: segfault at c0c73214 ip 000002bcb4b8d695 sp 00000384517ac290 error 4 in libgobject-2.0.so.0.2800.8[2bcb4b57000+53000]
Sep 6 21:33:51 localhost klogd: [ 2173.203001] gmrun[15256]: segfault at a0f975d4 ip 000002fe73586695 sp 00000394b6256bc0 error 4 in libgobject-2.0.so.0.2800.8[2fe73550000+53000]
Sep 6 21:34:54 localhost klogd: [ 2236.277513] gmrun[17934]: segfault at cde31394 ip 0000025962765695 sp 000003850290b930 error 4 in libgobject-2.0.so.0.2800.8[2596272f000+53000]

The new system log entries:

PCMANFM
Sep 21 18:28:00 localhost pcmanfm: stack smashing attack in function <unknown> - terminated
Sep 21 18:28:00 localhost Report to http://bugs.gentoo.org/

GMRUN:
Sep 21 18:28:06 localhost klogd: [ 1200.880180] gmrun[23412]: segfault at 3066c074 ip 00000348d5908d01 sp 000003aacf8e5b10 error 4 in libgobject-2.0.so.0.2800.8[348d58d0000+58000]

Here are the results in the terminal when I attempt to launch these apps from the terminal on the new system:

XXXXXXX@localhost ~ $ pcmanfm
*** stack smashing detected ***: pcmanfm - terminated
pcmanfm: stack smashing attack in function <unknown> - terminated
Report to http://bugs.gentoo.org/
Killed

XXXXXXXXX@localhost ~ $ gmrun
Segmentation fault

And the link to the gentoo bug for libfm on amd64 hardened is found here. (At least, I think that is the same bug. I'm in quite a bit over my head here.) I'm not using crazy CFLAGS either: CFLAGS="-march=native -O2 -pipe"

paxctl though should only be used on main executables, not on libraries, as it has no effect on libraries.

I thought about that after I posted it. It's paxctl -m /path/to/binary not /path/to/lib.

It may, when GRKERNSEC_MODHARDEN is enabled.

It is enabled, but automounting won't happen in Gentoo unless I specifically enable it, which I haven't done. I think I posted too early on the automounting issue, because I hadn't done my research. I will enable automounting and see if that makes a difference.

It's unfortunately necessary due to a userland vulnerability in udisks that by default allows filesystems of any type to be loaded by a non-root user (prior to some additional security features in grsecurity, this udisks vulnerability allowed any installed kernel module to be loaded by a non-root user).

I will have to revisit this issue once I have attempted and hopefully succeeded at enabling automounting, although it may not be an issue since I will keep modules built in.

gradm is the utility for that.

That's it. I have read about it lightly, but not deeply, until I have everything in order first.

Do I understand this correctly? If a lib like libfm or gmrun receives these types of responses from a hardened system, then it means the lib or app itself is insecure, due to errors in coding, and you wouldn't want it on your system until the coding error is fixed anyway?

[nomuus]

I am able to reproduce this on hardened Gentoo, pcmanfm-0.9.9 and libfm-0.1.16 both compiled under the hardened profile.

Here's a strace of /usr/bin/pcmanfm:

Code: Select all

open("/usr/share/libfm/archivers.list", O_RDONLY) = 10
fstat(10, {st_mode=S_IFREG|0644, st_size=2203, ...}) = 0
read(10, "[file-roller]\ncreate=file-roller"..., 4096) = 2203
read(10, "", 4096)                      = 0
close(10)                               = 0
socket(PF_FILE, SOCK_DGRAM, 0)          = 10
connect(10, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 EPROTOTYPE (Protocol wrong type for socket)
close(10)                               = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 10
connect(10, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0
write(2, "*** stack smashing detected ***:"..., 54*** stack smashing detected ***: pcmanfm - terminated
) = 54
write(10, "*** stack smashing detected ***:"..., 54) = 54
write(2, "pcmanfm: stack smashing attack i"..., 66pcmanfm: stack smashing attack in function <unknown> - terminated
) = 66
write(10, "pcmanfm: stack smashing attack i"..., 66) = 66
write(2, "Report to http://bugs.gentoo.org"..., 35Report to http://bugs.gentoo.org/\0


Restricting the permissions on /usr/share/libfm/archivers.list or moving it to another location causes pcmanfm to load. Modified the file to be empty, set the permissions back to 644 and the process was killed as before.

Next a [not so thorough] search of the libfm 1.1.16 code turned up a reference to the archivers.list file in fm-archiver.c.

http://pcmanfm.git.sourceforge.net/git/gitweb.cgi?p=pcmanfm/libfm;a=blob;f=src/base/fm-archiver.c;h=2852058501f1eb2c6f1988f6f77e432b2ed2d3db;hb=618ac2f9b05d56b0739d2d3d68611557791959df

Perhaps it could be something related to _fm_archiver_init(), though I am not quite sure, the strace is the only information that I've gathered. Any other points of interest that I can research?

[nomuus]

Looks like there is already an existing bug report filed for Gentoo confirming the aforementioned findings, see https://bugs.gentoo.org/show_bug.cgi?id=358435