[tahoe-lafs-trac-stream] [tahoe-lafs] #982: grsec disallows tahoe from learning its own IP address

[tahoe-lafs]

#982: grsec disallows tahoe from learning its own IP address
-------------------------+----------------------------
     Reporter:  ioerror  |      Owner:  warner
         Type:  defect   |     Status:  new
     Priority:  minor    |  Milestone:  undecided
    Component:  code     |    Version:  1.6.0
   Resolution:           |   Keywords:  security grsec
Launchpad Bug:           |
-------------------------+----------------------------

Comment (by zooko):

 So, is it the intent of someone who is running tahoe under grsec's "high"
 security mode that tahoe shouldn't be allowed to learn its own IP address?
 Or is it the intent that this would be okay for tahoe to learn its own IP
 address, but not okay to open {{{/proc/net/dev}}} for reading?

 If the former, then I agree that with ioerror's comment:2 that tahoe
 should handle failure of {{{getmyipaddr()}}} (which may require manual
 configuration of the IP address on the part of the user, or may involve
 tahoe running without knowing its IP address, which it can do with
 potentially reduced functonality). If the latter, then we should figure
 out a way to learn our IP address which doesn't require such high
 privileges that grsec denies it.

 The way tahoe is currently trying to learn its IP address is by running
 {{{/sbin/ifconfig}}} without any elevated privileges
 ([source:trunk/src/allmydata/util/iputil.py?annotate=blame&rev=4971#L177
 soure code]). What if grsecurity allowed {{{/sbin/ifconfig}}} to have
 read-only access to {{{/proc/net/dev}}} when it ({{{/sbin/ifconfig}}})
 doesn't have any elevated privileges? Would that fit the intent of
 grsecurity users?

 This is more a question for grsecurity folks than Tahoe-LAFS folks, so
 I'll post a note to their mailing list to ask.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/982#comment:5>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage