grsec disallows tahoe from learning its own IP address #982

New Issue

ioerror · 2010-03-05T08:49:13Z

ioerror commented

2010-03-05 08:49:13 +00:00

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.

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 added the

labels 2010-03-05 08:49:13 +00:00

ioerror added this to the undecided milestone 2010-03-05 08:49:13 +00:00

ioerror commented

2010-03-05 08:54:46 +00:00

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 [-] [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 [-]Failure ]
2010-03-05 00:29:47-0800 [-] calling os.abort()
2010-03-05 00:29:47-0800 [-] calling os.abort()

``` 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 [-] [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 [-]Failure ] 2010-03-05 00:29:47-0800 [-] calling os.abort() 2010-03-05 00:29:47-0800 [-] calling os.abort() ```

ioerror commented

2010-03-06 03:25:33 +00:00

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)

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 commented

2011-06-17 04:49:24 +00:00

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.

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 changed title from ~~Tahoe and grsec~~ to grsec disallows tahoe from learning its own IP address

2011-06-17 04:49:24 +00:00

zooko commented

2011-06-17 05:01:56 +00:00

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:76021 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]source:trunk/src/allmydata/util/iputil.py?annotate=blame&rev=4971#L177). 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.

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:76021](/tahoe-lafs/trac-2024-07-25/issues/982#issuecomment-76021) 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]source:trunk/src/allmydata/util/iputil.py?annotate=blame&rev=4971#L177). 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 commented

2011-06-17 05:08:14 +00:00

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

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

ioerror commented

2011-06-17 05:24:25 +00:00

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.

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 commented

2011-06-17 12:15:17 +00:00

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?

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 commented

2011-06-17 12:16:23 +00:00

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.

Replying to [ioerror](/tahoe-lafs/trac-2024-07-25/issues/982#issuecomment-76026): > 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 commented

2013-05-27 17:29:42 +00:00

See #1988.

Daira Hopwood <david-sarah@jacaranda.org> commented

2013-06-25 18:15:57 +00:00

In /tahoe-lafs/trac-2024-07-25/commit/a493ee0bb641175ecf918e28fce4d25df15994b6:

iputil.py: add tests for recent changes. refs #1381, #1988, #982, #1064, #1536, #1935, #898, #1707, #1918

Signed-off-by: Daira Hopwood <david-sarah@jacaranda.org>

In [/tahoe-lafs/trac-2024-07-25/commit/a493ee0bb641175ecf918e28fce4d25df15994b6](/tahoe-lafs/trac-2024-07-25/commit/a493ee0bb641175ecf918e28fce4d25df15994b6): ``` iputil.py: add tests for recent changes. refs #1381, #1988, #982, #1064, #1536, #1935, #898, #1707, #1918 Signed-off-by: Daira Hopwood <david-sarah@jacaranda.org> ```

daira commented

2013-06-27 01:55:22 +00:00

Replying to 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().

This might be fixed on trunk; it depends on whether 'ip addr' has the same problem as 'ifconfig'. I don't have grsec enabled in order to test this (and don't want to enable it because I don't have time to fix anything it breaks).

Replying to [ioerror](/tahoe-lafs/trac-2024-07-25/issues/982#issuecomment-76021): > 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(). This *might* be fixed on trunk; it depends on whether '`ip addr`' has the same problem as '`ifconfig`'. I don't have grsec enabled in order to test this (and don't want to enable it because I don't have time to fix anything it breaks).

warner was unassigned by tahoe-lafs

2013-06-27 01:55:22 +00:00

ioerror was assigned by tahoe-lafs

2013-06-27 01:55:22 +00:00

daira commented

2015-03-27 10:44:47 +00:00

Note that as a side-effect of the fix to #754 (which will be released in Tahoe-LAFS 1.10.1), setting tub.location without including "AUTO" will skip the local IP auto-detection code entirely, thus allowing a workaround for this problem if the other changes on trunk didn't fix it.

Note that as a side-effect of the fix to #754 (which will be released in Tahoe-LAFS 1.10.1), setting `tub.location` without including "`AUTO`" will skip the local IP auto-detection code entirely, thus allowing a workaround for this problem if the other changes on trunk didn't fix it.

Sign in to join this conversation.