Message "Insecure world writable dir ..."

[Harry Ohlsen]

When File.popen() is passed an executable whose path contains a world writable directory, it produces a warning message.

While I think this is a good idea, I have no control over the permissions on one such directory, and it's driving me nuts seeing the warning twenty times whenever I run that script.

Is there a way to disable the warning ... other than re-building the ruby executable without it?

Thanks in advance,

Harry O.

 

[Yukihiro Matsumoto]

Hi,

In message "Message "Insecure world writable dir ...""
|
|When File.popen() is passed an executable whose path contains a world writable directory, it produces a warning message.
|
|While I think this is a good idea, I have no control over the permissions on one such directory, and it's driving me nuts seeing the warning twenty times whenever I run that script.
|
|Is there a way to disable the warning ... other than re-building the ruby executable without it?

'-W0' if you're using 1.8; but I strongly recommend to fix the
permission problem.

matz.

 

[Dave Brown]

: In message "Message "Insecure world writable dir ...""
: |
: |When File.popen() is passed an executable whose path contains a world
: writable directory, it produces a warning message.
: |
: |While I think this is a good idea, I have no control over the
: permissions on one such directory, and it's driving me nuts seeing the
: warning twenty times whenever I run that script.
: |
: |Is there a way to disable the warning ... other than re-building the
: ruby executable without it?
:
: '-W0' if you're using 1.8; but I strongly recommend to fix the
: permission problem.

On every Unix system in the world, /tmp is world-writable, but it
also has the "sticky" bit set: permission 01777. That's not
considered to be an insecure permission setting; only the person
who owns a file in /tmp can remove it or modify it.

If Ruby complains about a directory with permission 0777, then it
has a point, but if it complains about a directory with permission
01777, then it's being overzealous.

--Dave

 

[Ben Giddings]

Hi,

In message "Message "Insecure world writable dir ...""
|
|When File.popen() is passed an executable whose path contains a world writable directory, it produces a warning message.
|
|While I think this is a good idea, I have no control over the permissions on one such directory, and it's driving me nuts seeing the warning twenty times whenever I run that script.
|
|Is there a way to disable the warning ... other than re-building the ruby executable without it?

'-W0' if you're using 1.8; but I strongly recommend to fix the
permission problem.

Hi Matz,

Could you (or someone else) explain what the rationale behind this message
is? What sort of thing is it meant to prevent? I get it all the time
because I have some odd permissions on some of my directories. I don't see
it as an issue, because the security concerns are taken care of in other
ways. It seems odd to me that File.popen() (and '`' and 'system') would
complain about a world-writeable-directory, or even do any security checks,
unless you explicitly set some variable.

Am I missing something obvious?

Ben

 

[Harry Ohlsen]

Hi Matz,

Could you (or someone else) explain what the rationale behind this
message is? What sort of thing is it meant to prevent? I get it all
the time because I have some odd permissions on some of my directories.
I don't see it as an issue, because the security concerns are taken care
of in other ways. It seems odd to me that File.popen() (and '`' and
'system') would complain about a world-writeable-directory, or even do
any security checks, unless you explicitly set some variable.

Am I missing something obvious?

IANM, but ...

Imagine that, say, /export/home is world writeable. I could make a copy of someone's home directory, say "fred" and change some files in there (eg a script or executable). If I then move "fred" to "fred.original" and replace it with my modified version, then Fred might run my trojan script/executable.

This allows me to get something done and have it look like Fred did it. This could be, for example, sending an e-mail, or pretty much anything else I want. Equally, I might be interested in doing something using Fred's permissions that I might not be allowed to do with my own.

While this is fun, it's not a good thing .

Cheers,

Harry O.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Message "Insecure world writable dir ...""

|On every Unix system in the world, /tmp is world-writable, but it
|also has the "sticky" bit set: permission 01777. That's not
|considered to be an insecure permission setting; only the person
|who owns a file in /tmp can remove it or modify it.
|
|If Ruby complains about a directory with permission 0777, then it
|has a point, but if it complains about a directory with permission
|01777, then it's being overzealous.

Don't worry; sticky bit is checked if S_ISVTX is defined.

matz.

 

[Dave Brown]

: In message "Re: Message "Insecure world writable dir ...""
:
: |On every Unix system in the world, /tmp is world-writable, but it
: |also has the "sticky" bit set: permission 01777. That's not
: |considered to be an insecure permission setting; only the person
: |who owns a file in /tmp can remove it or modify it.
: |
: |If Ruby complains about a directory with permission 0777, then it
: |has a point, but if it complains about a directory with permission
: |01777, then it's being overzealous.
:
: Don't worry; sticky bit is checked if S_ISVTX is defined.

How about this case then?

[/tmp] irb
irb(main):001:0> system("echo hi")
(irb):1: warning: Insecure world writable dir /tmp/., mode 041777
hi
=> true
irb(main):002:0>

My feeling is that it's being overzealous there. (It does that
with exec too.)

--Dave

 

[Ben Giddings]

Imagine that, say, /export/home is world writeable. I could make a
copy of someone's home directory, say "fred" and change some files in
there (eg a script or executable). If I then move "fred" to
"fred.original" and replace it with my modified version, then Fred
might run my trojan script/executable.

Right, but say you create such a trojan -- the trojan is the danger,
not the fact the directory is world writeable. Running such a trojan
from within Ruby isn't any more dangerous from running it directly,
right?

Unless the danger is ruby-related, I don't see why Ruby tells you about
it. For example, does the HTTP module warn you when you use 'basic'
authentication, explaining that it isn't very secure? Does it warn you
that you're running Windows, an OS known to have lots of security
flaws?

I can see the complaint about world writable directories containing
binaries in a security auditing module, but I'm not convinced about
popen/system/`

Ben

 

[Harry Ohlsen]

Right, but say you create such a trojan -- the trojan is the danger, not
the fact the directory is world writeable.

Well, the fact that the directory is world writable is also a danger, since (a) it allowed you to create the trojan in the first place and (b) while it remains writable, other trojans can be created.

Running such a trojan from
within Ruby isn't any more dangerous from running it directly, right?
True.

Unless the danger is ruby-related, I don't see why Ruby tells you about
it. For example, does the HTTP module warn you when you use 'basic'
authentication, explaining that it isn't very secure? Does it warn you
that you're running Windows, an OS known to have lots of security flaws?

I think world writable directories are far more serious than those two examples. The others require some effort to break the system (albeit small, for a true cracker). World writeable directories in one's execution path can be used for nefarious purposes with almost zero effort.

I can see the complaint about world writable directories containing
binaries in a security auditing module, but I'm not convinced about
popen/system/`

I agree it's a little strange having Ruby tell you about security issues, but since it's a real and potentially very serious problem, I think it's reasonable that it does. I'd just prefer it if one could turn warnings off individually, if there is no way to have the problem fixed.

As it happens, I convinced the sysadmin here that it truly was a security risk and he's fixed it. However, I could imagine very open environments where people might want to have world writable directories like that, because everyone is considered highly trustworthy and having such security would be an unnecessary hindrance.

Cheers,

Harry O.

 

[Thien Vuong]

Right, but say you create such a trojan -- the trojan is the danger, not
the fact the directory is world writeable. Running such a trojan from
within Ruby isn't any more dangerous from running it directly, right?

Unless the danger is ruby-related, I don't see why Ruby tells you about
it. For example, does the HTTP module warn you when you use 'basic'
authentication, explaining that it isn't very secure? Does it warn you
that you're running Windows, an OS known to have lots of security flaws?

I can see the complaint about world writable directories containing
binaries in a security auditing module, but I'm not convinced about
popen/system/`

It seems that this warning is only issued if the affected directory is
in the path. So I guess it is a could be construed as a security issue
for popen/system/exec in ruby. But it was not clear from the message at
all and seems to imply ruby does not like the setting - which bother
user because most time they have no control over it.

Thien

 

[Thien Vuong]

Thien Vuong wrote:

It seems that this warning is only issued if the affected directory is
in the path. So I guess it is a could be construed as a security issue
for popen/system/exec in ruby. But it was not clear from the message at
all and seems to imply ruby does not like the setting - which bother
user because most time they have no control over it.

The fix/workaround is to remove the component out of the path (or ".").
Don't have to change the dir setting. Unless one insists on executing
out of those directory.

 

[Harry Ohlsen]

Thien Vuong wrote:

The fix/workaround is to remove the component out of the path (or ".").
Don't have to change the dir setting. Unless one insists on executing
out of those directory.

Note that the warning is produced if *any* sub-directory of a directory in the path is world writable. For example, in my case, I have my own "bin" directory in the path ... /export/home/harryo/bin. That directory isn't world writable, but Ruby picks up that one of the directories above it is (ie, /export/home in this case).

H.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Message "Insecure world writable dir ...""

|: Don't worry; sticky bit is checked if S_ISVTX is defined.
|
|How about this case then?
|
| [/tmp] irb
| irb(main):001:0> system("echo hi")
| (irb):1: warning: Insecure world writable dir /tmp/., mode 041777
| hi
| => true
| irb(main):002:0>
|
|My feeling is that it's being overzealous there. (It does that
|with exec too.)

Oops, check was incomplete. Thank you for the report.

matz.

 

[Thien Vuong]

Thien Vuong wrote:




Note that the warning is produced if *any* sub-directory of a directory
in the path is world writable. For example, in my case, I have my own
"bin" directory in the path ... /export/home/harryo/bin. That directory
isn't world writable, but Ruby picks up that one of the directories
above it is (ie, /export/home in this case).

H.

Hm, I don't have the same result


[1.21:14:22] tvuong>cd /tmp
[2.21:14:26] tmp>PATH=".:/bin:/home/eng/tools/bin"
[3.21:14:39] tmp>irb-1.8
irb(main):001:0> system "date"
(irb):1: warning: Insecure world writable dir /tmp/., mode 041777
Mon Nov 24 21:14:49 PST 2003
=> true
irb(main):002:0>

[8.21:16:41] tmp>ls -ld ./bin
drwxrwxr-x 2 tvuong eng 69 Nov 24 21:11 ./bin

irb(main):004:0>
[4.21:15:04] tmp>cd ./bin

[6.21:15:13] bin>irb-1.8
irb(main):001:0> system "date"
Mon Nov 24 21:15:24 PST 2003
=> true
irb(main):002:0>
[7.21:15:25] bin>

 

[Harry Ohlsen]

Note that the warning is produced if *any* sub-directory of a
directory in the path is world writable. For example, in my case, I
have my own "bin" directory in the path ... /export/home/harryo/bin.
That directory isn't world writable, but Ruby picks up that one of the
directories above it is (ie, /export/home in this case).

H.

Hm, I don't have the same result


[1.21:14:22] tvuong>cd /tmp
[2.21:14:26] tmp>PATH=".:/bin:/home/eng/tools/bin"
[3.21:14:39] tmp>irb-1.8
irb(main):001:0> system "date"
(irb):1: warning: Insecure world writable dir /tmp/., mode 041777
Mon Nov 24 21:14:49 PST 2003
=> true
irb(main):002:0>

[8.21:16:41] tmp>ls -ld ./bin
drwxrwxr-x 2 tvuong eng 69 Nov 24 21:11 ./bin

I'm not sure I understand what you mean.

It's not complaining about ./bin, it's complaining about "/tmp/." (ie, "/tmp") in this case. The modes on ./bin aren't the issue ... or did I misunderstand what you were saying?

H.

 

[Thien Vuong]

Note that the warning is produced if *any* sub-directory of a
directory in the path is world writable. For example, in my case, I
have my own "bin" directory in the path ... /export/home/harryo/bin.
That directory isn't world writable, but Ruby picks up that one of
the directories above it is (ie, /export/home in this case).

H.

Hm, I don't have the same result


[1.21:14:22] tvuong>cd /tmp
[2.21:14:26] tmp>PATH=".:/bin:/home/eng/tools/bin"
[3.21:14:39] tmp>irb-1.8
irb(main):001:0> system "date"
(irb):1: warning: Insecure world writable dir /tmp/., mode 041777
Mon Nov 24 21:14:49 PST 2003
=> true
irb(main):002:0>

[8.21:16:41] tmp>ls -ld ./bin
drwxrwxr-x 2 tvuong eng 69 Nov 24 21:11 ./bin

I'm not sure I understand what you mean.

It's not complaining about ./bin, it's complaining about "/tmp/." (ie,
"/tmp") in this case. The modes on ./bin aren't the issue ... or did I
misunderstand what you were saying?

H.

I though you said that if any part of the subdirectory has the
permission issue it would complain, as in

only /export/home has permission problem
your path contains /export/home/harryo/bin does not have permission problem

but ruby still issue warning, so my test was

/tmp has permission problem
/tmp/bin does not have permission problem

ruby does not complain when /tmp/bin (permission is OK) is in the path,
only when /tmp (permission is bad) is in the path. Sorry if I
misunderstood your point

Thien

 

[Harry Ohlsen]

Thien Vuong wrote:

but ruby still issue warning, so my test was

/tmp has permission problem
/tmp/bin does not have permission problem

ruby does not complain when /tmp/bin (permission is OK) is in the path,
only when /tmp (permission is bad) is in the path. Sorry if I
misunderstood your point

But your path has "." in it. Since you're sitting in /tmp, that explains this warning ...

[1.21:14:22] tvuong>cd /tmp
[2.21:14:26] tmp>PATH=".:/bin:/home/eng/tools/bin"
[3.21:14:39] tmp>irb-1.8
irb(main):001:0> system "date"
(irb):1: warning: Insecure world writable dir /tmp/., mode 041777

However, when you cd into bin (ie, /tmp/bin), "." is now /tmp/bin, not /tmp.

However, I see your point. Perhaps Ruby only complains about directories that are literally in the path, and doesn't convert "." before doing the check. So, in this case it's not looking at both /tmp and /tmp/bin, just ".", which is /tmp/bin ... but that's just a guess.

You could try changing your path to "/tmp/bin:/bin:/home/eng/tools/bin" and see if you get the error then. I would expect you to, but am not sure.

Cheers,

Harry O.

 

[nobu.nokada]

Hi,

At Tue, 25 Nov 2003 11:42:13 +0900,

How about this case then?

[/tmp] irb
irb(main):001:0> system("echo hi")
(irb):1: warning: Insecure world writable dir /tmp/., mode 041777
hi
=> true
irb(main):002:0>

My feeling is that it's being overzealous there. (It does that
with exec too.)

Do you really include /tmp/. in your PATH? Incredibly
dangerous!

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Message "Insecure world writable dir ...""

|Do you really include /tmp/. in your PATH? Incredibly
|dangerous!

No, it happens when the current directory is /tmp, and when $LOAD_PATH
includes "." (default).

matz.