[grsec] a couple of questions about grsec policies for Tahoe-LAFS

[Brad Spengler]

> Jacob Appelbaum ran Tahoe-LAFS on grsec and reported two problems. If
> you could please have a look at these two issues and let us Tahoe-LAFS
> developers know how grsec thinks about such things I would appreciate
> it:
> 
> http://tahoe-lafs.org/trac/tahoe-lafs/ticket/982# grsec disallows
> tahoe from learning its own IP address
> http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1421# increase_rlimits()
> tries to set RLIMIT_CORE high, which grsec disallows

These aren't bugs :) For the first issue, it's a matter of reading the 
configuration help for the options that were enabled.  In this case, 
CONFIG_GRKERNSEC_PROC_USERGROUP is enabled by grsec on the 'high' 
setting.  This denies non-root users from viewing /proc/net, *except* 
for those in a special GID (1001 by default, which I imagine wasn't 
changed).  That gid should have been visible when listing /proc.  One 
solution is to require users needing to run this to be assigned to the 
special group.

For the second issue, it's likely due to fallout from the first -- the 
application tried to coredump, but was unable to.  This wasn't due to 
grsecurity, but rather due to your existing resource limits.  grsecurity 
in this case is only logging the event.

-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://grsecurity.net/pipermail/grsecurity/attachments/20110617/c564b7f1/attachment.pgp>