RE: [PLUG] what would cause the sticky bits to be set on files?

["George Gallen" <ggallen@slackinc.com>]

Title: RE: [PLUG] what would cause the sticky bits to be set on files?

>-----Original Message-----
>From: plug-bounces@lists.phillylinux.org
>[mailto:plug-bounces@lists.phillylinux.org]On Behalf Of Jeff Abrahamson
>Sent: Tuesday, December 28, 2004 11:38 AM
>To: plug@lists.phillylinux.org
>Subject: Re: [PLUG] what would cause the sticky bits to be set
>on files?
>
>You really, really didn't want to do that.
>
>Lots of things use /tmp, so, as you noted, /tmp has to be 777.  But
>here's what you don't want to happen:
>
>    you:    mkdir /tmp/private/
>           chmod 700 /tmp/private
>
>    me:            mkdir /tmp/other
>           chmod 777 /tmp/other
>           mv /tmp/other /tmp/private
>
>    you:    write stuff to /tmp/private thinking it's private

I am usually the only one who would be creating directories within
/tmp, with the exception of one other person, who I am pretty sure
hadn't created any files with the sticky bit set. Something fairly
recently must have reset the /tmp bits.

Could the normal bootup routine have checked that /tmp didn't have
the sticky bits set, and reset them? We did have a reboot 28 days
ago, and I'm pretty sure I've chmodded /tmp to 777 in the past.

I'm not as concerned about the implications of making /tmp 777 as
I am about how it's sticky bit was reset back on. (it's a really
localized machine and the internal security to it isn't that strong
mostly because access is fairly restricted, and nobody plays on the
machine (that I have been able to tell). We have 2 analysts including
myself, and I know the other doesn't play much with linux (that's mostly
my end).

I have noticed lately that a directory named "ZIPTEMP" within the /tmp
directory has been deleted twice since the reboot. I assumed it was
because it's in the /tmp and has "TEMP" as part of the name, so it was
hosed on the reboot, but something removed it again recently, and it was
only about 15 days since I last had created it.

I suspect these two incidents are related, but I'm not sure how.

George

>
>Of course, this can be done in more subtle and clever ways, but this
>is the essence of the attack.
>
>Moreover, by doing a chmod -R 777, this means, for example, that
>everyone can read and write to your ssh-agent's socket.
>
>    jeff@asterix:jeff $ env |grep SSH
>    SSH_AGENT_PID=24442
>    SSH_AUTH_SOCK=/tmp/ssh-xziUW24393/agent.24393
>    jeff@asterix:jeff $
>
>and other things like this that are supposed to be private.
>
>That's why /tmp has the funky mod bits and why some things in /tmp
>aren't world readable/writable.

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug