grsec disallows tahoe from learning its own IP address

[ioerror]

I'm attempting to run Tahoe with a Linux kernel that uses grsec (2.6.32.9 with the corresponding grsec patch).

It appears that the high security mode of grsec is incompatible with Tahoe.

Grsec disallows a resource overstep when Tahoe requests 4196256 for RLIMIT_CORE. To get Tahoe started, you'll need to add the following to the init.d script:

ulimit -c 4196256

Futhermore, it appears that Tahoe has an unhandled error when it cannont open /proc/net/dev (it's not there for normal users in high security mode). This causes Tahoe to call os.abort() and Tahoe fails to start.

[ioerror]

2010-03-05 00:29:47-0800 [-] Log opened.
2010-03-05 00:29:47-0800 [-] twistd 8.1.0 (/usr/bin/python 2.5.2) starting up
2010-03-05 00:29:47-0800 [-] reactor class: <class 'twisted.internet.selectreactor.SelectReactor'>
2010-03-05 00:29:47-0800 [-] foolscap.pb.Listener starting on 54934
2010-03-05 00:29:47-0800 [-] nevow.appserver.NevowSite starting on 3456
2010-03-05 00:29:47-0800 [-] Starting factory <nevow.appserver.NevowSite instance at 0x1cc9a28>
2010-03-05 00:29:47-0800 [-] My pid: 3011
2010-03-05 00:29:47-0800 [-] twisted.internet.protocol.DatagramProtocol starting on 57020
2010-03-05 00:29:47-0800 [-] Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x1ae15a8>
2010-03-05 00:29:47-0800 [-] (Port 57020 Closed)
2010-03-05 00:29:47-0800 [-] Stopping protocol <twisted.internet.protocol.DatagramProtocol instance at 0x1ae15a8>
2010-03-05 00:29:47-0800 [-] Unhandled Error
        Traceback (most recent call last):
        Failure: exceptions.IOError: got stderr: 'Warning: cannot open /proc/net/dev (No such file or directory). Limited output.\n'
        
2010-03-05 00:29:47-0800 [-] Node._startService failed, aborting
2010-03-05 00:29:47-0800 [-] [Failure instance: Traceback (failure with no frames): <type 'exceptions.IOError'>: got stderr: 'Warning: cannot open /proc/net/dev (No such file or directory). Limited output.\n'
2010-03-05 00:29:47-0800 [-] ]
2010-03-05 00:29:47-0800 [-] calling os.abort()
2010-03-05 00:29:47-0800 [-] calling os.abort()

[ioerror]

It seems that Tahoe will call ifconfig and it won't work in "high" security mode. Tahoe calls ifconfig to determine it's network location. grsec doesn't allow /proc/net/dev for non-root users. ifconfig complains to stderr message (as listed above), Tahoe sees this message and getmyipaddr() returns None. In addition if tub.location is not set then the node will have no location, concludes it will be unable to start up, and bails with aus.abort().

We need the following things:

• getmyipaddr() should return None if ifconfig fails and not complain so much
• if getmyipaddr() fails but tub.location is set, we should proceed normally
• if getmyipaddr() fails and tub.location is unset, we should tell the user to please set tub.location and perhaps fail or maybe start up (client may still work)

[zooko]

I opened #1421 (increase_rlimits() tries to set RLIMIT_CORE high, which grsec disallows) to track the part about RLIMIT_CORE and am renaming this one to be more specifically about getmyipaddr() and /proc/net/dev.

[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 (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.

[zooko]

ndurner pointed out on IRC that ​http://icanhazip.com tells you the IP address that your HTTP connection is coming from. :-)

[ioerror]

I think it's fine to learn your own IP address but not by attempting to read from /proc/ or using any tools on the system that may read from /proc or other such subsystems such as /sys.

An idea: Allow Tahoe to learn it's own likely IP address by talking to another peer or checking for a configuration option. Thus a user can manually set the tub.location or Tahoe can learn it from the introducer;

In Tor, we allow any OR to talk to another OR and ask for it's own IP address. This peer IP is often correct. The OR then attempts to connect back to test if it has incoming ports filtered or open. That may also be quite useful for Tahoe.

[zooko]

Thanks, ioerror!

Also last night I posted to the grsec mailing list asking about this: ​http://grsecurity.net/pipermail/grsecurity/2011-June/001083.html

So, why doesn't grsec provide a way for apps to learn what IP address is configured on certain interfaces without thereby giving that app any broader power that it could abuse?

[zooko]

Replying to ioerror:

An idea: Allow Tahoe to learn it's own likely IP address by talking to another peer or checking for a configuration option. Thus a user can manually set the tub.location or Tahoe can learn it from the introducer;

In Tor, we allow any OR to talk to another OR and ask for it's own IP address. This peer IP is often correct. The OR then attempts to connect back to test if it has incoming ports filtered or open. That may also be quite useful for Tahoe.

We did something similar in Mnet. It worked well.

[zooko]

See #1988.