[grsec] a couple of questions about grsec policies for Tahoe-LAFS
Brad Spengler
spender at grsecurity.net
Fri Jun 17 07:59:21 EDT 2011
> 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>
More information about the grsecurity
mailing list