grsec disallows tahoe from learning its own IP address

ioerror commented

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

Owner

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.

tahoe-lafs added the

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

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

ioerror commented

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

Author

Owner

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

Author

Owner

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

Author

Owner

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`.

tahoe-lafs 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

Author

Owner

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:117712 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:117712](/tahoe-lafs/trac-2024-07-25/issues/982#issuecomment-117712) 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

Author

Owner

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

Author

Owner

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

Author

Owner

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

Author

Owner

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-117717): > 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

Author

Owner

See #1988.

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

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

Author

Owner

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

Author

Owner

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-117712): > 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).

daira commented

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

Author

Owner

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.

grsec disallows tahoe from learning its own IP address #982