users and developpers discussion about Grsecurity

Zooko O'Whielacronx | 17 Jun 2011 07:19

a couple of questions about grsec policies for Tahoe-LAFS

Dear grsecurity folks:

I'm a developer on Tahoe-LAFS, a secure and fault-tolerant cloud storage system:

http://tahoe-lafs.org

I've recently gotten more interested in having a hardened operating
system under Tahoe-LAFS deployments.

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

Thanks!

If you go ahead and register on the Tahoe-LAFS trac in order to update
the ticket, that will be the best way to communicate with the
Tahoe-LAFS developers (who are far more than just me), but if you
don't want to register and you just reply to this message then I'll
cut and paste your reply into those tickets.

Regards,

Zooko

(Continue reading)

headers

Brad Spengler | 17 Jun 2011 13:59

Re: a couple of questions about grsec policies for Tahoe-LAFS

> 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

_______________________________________________
grsecurity mailing list
grsecurity@...

(Continue reading)