Mailing List Archive

GrSecurity: slow learning mode & incomplete policy
I have some troubles with GrSecurity learning mode and did not find
any answer in https://en.wikibooks.org/wiki/Grsecurity/The_Administration_Utility#Learning_Mode
Their ML appears to be dead, or restricted to announces now.

1) I let "gradm -F -L ..." run for a couple of weeks, then threw the
logs to "gradm -F -L ... -O ...".
It generated a rather restrictive policy, I twiked some rules, and
when I implemented the policy, some programs were blocked although
they had been seen many times (for example, Postfix components).
I added "l" (learn) flags to the impacted "subjects", ran the learning
process again and fixed most problems.

Anyway, I still saw bizarre messages, e.g.:
(default:D:/) denied access to hidden file /etc/localtime by
/usr/sbin/fetchnews[fetchnews:22855] uid/euid:9/9 gid/egid:13/13,
parent /etc/cron.daily/fetchnews[fetchnews:22854] uid/euid:0/0
gid/egid:0/0 /usr/sbin/fetchnews

I don't understand why the default role complains here: I have a role
for the "news" user and all programs than run under its UID avec an
associated subject.

2) (incremental) learning of the news logs is awfully slow.

# gradm -L /tmp/learning.logs -O /tmp/policy
Beginning full learning object reduction for subject /usr/sbin/uptimed...done.
[snip]
Beginning full learning object reduction for subject /...

The first subjects appeared quickly. Now, gradm has spend days on /
using 100% CPU (on one core) and 1 GB.

What mistake did I make?
Re: GrSecurity: slow learning mode & incomplete policy [ In reply to ]
On 09/14/14 08:28, Michel Arboi wrote:
> I have some troubles with GrSecurity learning mode and did not find
> any answer in https://en.wikibooks.org/wiki/Grsecurity/The_Administration_Utility#Learning_Mode
> Their ML appears to be dead, or restricted to announces now.
>
> 1) I let "gradm -F -L ..." run for a couple of weeks, then threw the
> logs to "gradm -F -L ... -O ...".
> It generated a rather restrictive policy, I twiked some rules, and
> when I implemented the policy, some programs were blocked although
> they had been seen many times (for example, Postfix components).
> I added "l" (learn) flags to the impacted "subjects", ran the learning
> process again and fixed most problems.
>
> Anyway, I still saw bizarre messages, e.g.:
> (default:D:/) denied access to hidden file /etc/localtime by
> /usr/sbin/fetchnews[fetchnews:22855] uid/euid:9/9 gid/egid:13/13,
> parent /etc/cron.daily/fetchnews[fetchnews:22854] uid/euid:0/0
> gid/egid:0/0 /usr/sbin/fetchnews
>
> I don't understand why the default role complains here: I have a role
> for the "news" user and all programs than run under its UID avec an
> associated subject.
>
> 2) (incremental) learning of the news logs is awfully slow.
>
> # gradm -L /tmp/learning.logs -O /tmp/policy
> Beginning full learning object reduction for subject /usr/sbin/uptimed...done.
> [snip]
> Beginning full learning object reduction for subject /...
>
> The first subjects appeared quickly. Now, gradm has spend days on /
> using 100% CPU (on one core) and 1 GB.
>
> What mistake did I make?
>

I don't see any, to be honest. 1) are you sure fetchnews ran at least
once during the learning? A couple of weeks is certainly long enough.
I wonder if its too long? 2) The cpu problems seems like a genuine bug.

We should probably open a proper bug reprot for this, but let me send
this upstream now.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
Re: GrSecurity: slow learning mode & incomplete policy [ In reply to ]
On Thu, Sep 18, 2014 at 12:31 AM, Anthony G. Basile
<basile@opensource.dyc.edu> wrote:
> I don't see any, to be honest. 1) are you sure fetchnews ran at least once
> during the learning?

Yes.
# grep fetchnews learning.logs | grep -v /backup | wc -l
132
# grep /etc/cron.daily/fetchnews learning.logs | grep -v /backup | wc -l
42
#

> 2) The cpu problems seems like a genuine bug.

Still running by the way.
21170 pts/2 RL+ 7004:37 gradm -L /tmp/learning.logs -O /tmp/policy
31255 pts/1 RL+ 18605:09 gradm -F -L /tmp/learning.logs -O
/etc/grsec/policy4
(I tried both commands, just in case)

The processor is not very fast (AMD Athlon II X4 610e) but this is really long.
Re: GrSecurity: slow learning mode & incomplete policy [ In reply to ]
On 18 Sep 2014 at 15:28, Michel Arboi wrote:

> > 2) The cpu problems seems like a genuine bug.
>
> Still running by the way.
> 21170 pts/2 RL+ 7004:37 gradm -L /tmp/learning.logs -O /tmp/policy
> 31255 pts/1 RL+ 18605:09 gradm -F -L /tmp/learning.logs -O
> /etc/grsec/policy4
> (I tried both commands, just in case)
>
> The processor is not very fast (AMD Athlon II X4 610e) but this is really long.

did you email spender with your problem and logs?
Re: GrSecurity: slow learning mode & incomplete policy [ In reply to ]
On Fri, Sep 19, 2014 at 9:09 PM, PaX Team <pageexec@freemail.hu> wrote:
> did you email spender with your problem and logs?

No. What's his e-mail?
Re: GrSecurity: slow learning mode & incomplete policy [ In reply to ]
On 20 Sep 2014 at 13:20, Michel Arboi wrote:

> On Fri, Sep 19, 2014 at 9:09 PM, PaX Team <pageexec@freemail.hu> wrote:
> > did you email spender with your problem and logs?
>
> No. What's his e-mail?

i put him on cc in my previous mail, you could have just hit 'reply all'...
Re: GrSecurity: slow learning mode & incomplete policy [ In reply to ]
On Thu, Sep 18, 2014 at 12:31 AM, Anthony G. Basile
<basile@opensource.dyc.edu> wrote:
> 2) The cpu problems seems like a genuine bug.

One of the commands finished:

# time gradm -F -L /tmp/learning.logs -O /etc/grsec/policy4
...
Beginning full learning object reduction for subject /...done.
Beginning full learning object reduction for subject
/usr/libexec/postfix/flush...done.
Beginning full learning object reduction for subject
/usr/libexec/postfix/pickup...done.
Beginning full learning object reduction for subject
/usr/libexec/postfix/qmgr...done.
Beginning full learning object reduction for subject
/usr/libexec/postfix/smtpd...done.
Full learning complete.

real 33882m8.627s <--- nearly 24 days
user 33271m45.443s
sys 66m10.247s
#