Jamie Nguyen
dysco****@gmail*****
Thu Jan 13 18:32:31 JST 2011
TOMOYO
ForkTetsuo Handa wrote:
> Jamie Nguyen wrote:
>> I would appreciate it if you could take a
>> look at the patch, as I was wondering if there are any serious
>> concerns about using both of these patches together? I am not sure if
>> they would do something unexpected and actually result in a huge
>> security flaw.
>
> I have no known issues with using both at the same time.
Great.
> I don't know how to use grsecurity. My worry is that grsecurity
> patch would let application repeat calling recv(MSG_PEEK) forever
> (i.e. CPU consumption loop in userland) due to
>
> try_again:
> skb = __skb_recv_datagram(sk, flags | (noblock ? MSG_DONTWAIT : 0),
> &peeked, &err);
> if (!skb)
> goto out;
> if (ccs_socket_post_recvmsg_permission(sk, skb, flags)) {
> err = -EAGAIN; /* Hope less harmful than -EPERM. */
> goto out;
> }
>
> err = gr_search_udp_recvmsg(sk, skb);
> if (err)
> goto out_free;
> (...snipped...)
> out_free:
> skb_free_datagram_locked(sk, skb);
> out:
> return err;
>
> (in file net/ipv4/udp.c ) if the application did not close the socket upon error.
> (TOMOYO calls skb_kill_datagram() in ccs_socket_post_recvmsg_permission()
> upon error in order to avoid CPU consumption pitfall).
Right, would you say this is a potential bug in grsecurity? If so, I
might go and ask on their ML why it has been done this way. If it does
indeed cause a cpu consumption loop, it looks to me like it would
occur even without ccs-patch.
> Anyway, in the trunk/1.8.x/ccs-patch/patches/ directory, ccs-patch for
> 2.6.32.28+grsecurity and 2.6.36.3+grsecurity are ready. (revision 4358)
Great thanks! :-)
I notice that the only significant changes in 2.6.32.28+grsecurity are
in fs/open.c, which look to me like it adjusts ccs-patch to catch
chown requests before grsecurity does? In 2.6.36.3+grsecurity, there
doesn't look to be any major changes needed (apart from accounting for
different lines).
For the 2.6.32.28+grsecurity patch, I am guessing that this needs to
be refreshed only when applying the patch fails? It is a long-term
kernel, so I assume that any new kernel patches or grsecurity patches
should not make any major changes, and that ccs-patch should apply
fine without having to be refreshed. I suppose I will let you know if
building breaks. Did it save you time for me to upload the test-patch?
If I get there before you do, I would be happy to refresh the
grsecurity patches (both 2.6.32.x and 2.6.36.x/2.6.37.x) and upload
them to my test-patches branch. I do not know what command you used to
create the diff though.
Kind regards