Creating policy from Full Learning log hangs

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

Creating policy from Full Learning log hangs

Postby TH3L0N3W0LF » Wed Dec 31, 2014 7:39 pm

Hey guys,

I apologize if this has already been asked. I searched the forums and the only post I could find that had relevance to my issue was made back in 2004. However, there was no real solution provided.

I installed the GrSecurity kernel as well as pax and gradm on my Desktop. Currently, it's running kernel version 3.18.1.201412310755-1-grsec and has no issues whatsoever. I was attempting to install it on my laptop as well when I ran into an issue.
On my desktop, I used gradm to enter full learning mode, and used it to generate a policy from the resulting log. There were no issues whatsoever enabling RBAC. However, when attempting to create a policy from a full learning mode log, gradm hangs, fully utilizes 100% of a single core, and does nothing. At first, I believed it was an issue with the size of the log file. It was the first time I generated a log larger than 100MB so I figured it would just take extra time to parse. I left it sitting overnight, and when I returned the next morning it was in the same state.

Attempting to run the command returns:
Code: Select all
root [grsec]$ gradm -F -L learning.log -O policy
Beginning full learning 1st pass...


and stays like this until it is killed. Nothing shows up in dmesg, and when I re-ran the command using strace, I found that at certain points, when reading the log file, it suddenly stopped and refused to continue. I removed the lines that it stopped at, but the result was the same, stopping at the line that came after the deleted one.

Example strace:
Code: Select all
...

fstat(5, {st_mode=S_IFREG|0644, st_size=1281, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x342c0534000
read(5, "root:x:0:root\nbin:x:1:root,bin,d"..., 4096) = 1281
close(5)                                = 0
munmap(0x342c0534000, 4096)             = 0
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=1866, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x342c0534000
read(5, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1866
close(5)                                = 0
munmap(0x342c0534000, 4096)             = 0
open("/etc/group", O_RDONLY|O_CLOEXEC)  = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=1281, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x342c0534000
read(5, "root:x:0:root\nbin:x:1:root,bin,d"..., 4096) = 1281
close(5)                                = 0
munmap(0x342c0534000, 4096)             = 0
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=1866, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x342c0534000
read(5, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1866
close(5)                                = 0
munmap(0x342c0534000, 4096)             = 0
open("/etc/group", O_RDONLY|O_CLOEXEC)  = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=1281, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x342c0534000
read(5, "root:x:0:root\nbin:x:1:root,bin,d"..., 4096) = 1281
close(5)                                = 0
munmap(0x342c0534000, 4096)             = 0
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=1866, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x342c0534000
read(5, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1866
close(5)                                = 0
munmap(0x342c0534000, 4096)             = 0
read(3, "2afabedea0703efc.png\t17\t0.0.0.0\n"..., 16777216) = 16777216
read(3, "/usr/lib/tumbler-1/tumblerd\t/\t1\t"..., 16777216) = 16777216
read(3, "00\t100\t/usr/lib/tumbler-1/tumble"..., 16777216) = 16777216
read(3, "ult\t68\t1000\t100\t/usr/lib/firefox"..., 16777216) = 16777216

At which point it stops running, while continuing to bog down a single core.
As a final act of desperation, I copied my log to my desktop where I succeeded making a policy before, but the desktop displayed the same issue as before.

The kernel I'm currently using is at version 3.18.1.201412310755, from the Arch Linux repositories.
Gradm is at version 3.0.201408301734.

I'm more than willing to provide whatever files may be necessary in order to help solve the problem. At this point, I don't know what else to try. Everything aside from RBAC policy creation via gradm works.

Any help would be appreciated.
TH3L0N3W0LF
 
Posts: 2
Joined: Wed Dec 31, 2014 6:11 pm

Re: Creating policy from Full Learning log hangs

Postby TH3L0N3W0LF » Wed Jan 07, 2015 2:05 pm

So,
I experimented a bit today and found something rather interesting.
I cut my policy in half (right before loading my desktop environment) and the policy
generates perfectly.

I began snipping away at portions of the log file to figure out what was causing the hang, and I narrowed it down to rhythmbox.
I cut it down again and found that it hangs only when reading over my music directory, which has song names that have
a couple of foreign characters in their names (夢想演舞, etc)

Could a lack of special unicode support and/or foreign character support be the cause of this? If so, is there a possibility of this being patched in the future?
TH3L0N3W0LF
 
Posts: 2
Joined: Wed Dec 31, 2014 6:11 pm


Return to grsecurity support