Tetsuo Handa
from-****@I-lov*****
Thu Jan 13 21:59:54 JST 2011
Jamie Nguyen wrote: > 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. I think whether this behavior is a bug or not depends on user's preferences. I consider that side effects like CPU power consumption ( http://www.youtube.com/watch?v=I8fF5mueWTw ) which would not have been occurred if the access request were granted by MAC as a bug. Therefore, in TOMOYO 1.x , (1) sleep penalty (2) execure handler (3) discard connections/datagrams in receive queue upon error are implemented. I don't want the system continue busy loop forever. But others do not care about side effects like CPU power consumption. They think that the connections/datagrams in receive queue should remain unchanged if rejected by MAC. Therefore, a LSM hook which is called after dequeuing a datagram (i.e. TOMOYO's ccs_socket_post_recvmsg_permission() and grsecurity's gr_search_udp_recvmsg()) are not provided (and AKARI cannot implement permission checks for incoming datagrams). > > 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! :-) Me too. Your patch taught me that ccs-patch-2.6.32-grsecurity-201006011506.diff has a bug. > 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? Yes. I aggregated permission check because grsecurity patch passed vfsmount . > In 2.6.36.3+grsecurity, there > doesn't look to be any major changes needed (apart from accounting for > different lines). Since 2.6.33, I'm embedding TOMOYO's hooks into LSM hooks where possible because all pathname related LSM hooks became available in 2.6.33. Thus, ccs-patch for 2.6.36.3+grsecurity is almost identical to ccs-patch for 2.6.36 . Although I'm not happy that LSM hooks are called by non syscall requests (e.g. stackable filesystems), not using LSM hooks is becoming error-prone because VFS part is recently changing heavily. > For the 2.6.32.28+grsecurity patch, I am guessing that this needs to > be refreshed only when applying the patch fails? Only when patch command started to print fuzz messages or large offset difference. > 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. Right. > I suppose I will let you know if > building breaks. Yes, please. > Did it save you time for me to upload the test-patch? I made ccs-patch-2.6.32-grsecurity-201101120010.diff from ccs-patch-2.6.32-grsecurity-201006011506.diff . I used branches/test-patches/ for diff'ing yours and mine (and found a bug). > 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. You can directly upload to trunk/1.8.x/ccs-patch/patches/ . > I do not know what command you used to > create the diff though. I'm using quilt for maintaining ccs-patch-\*.diff . $ cat ~/.quiltrc QUILT_REFRESH_ARGS='-u --diffstat --no-index --no-timestamps --sort' QUILT_DIFF_OPTS='-p' I'm using below command for diff'ing ccs-patch-\*.diff . #! /bin/sh diff "$@" | grep -v '^[<>] diff' | grep -v '^[<>] ---' | grep -v '^[<>] +++' | grep -vF -- '---' | grep -v '^[<>] @@' Regards.
TOMOYO
Fork