Re: [PLUG] YAFSD

[Jason Stelzer <jason.stelzer@gmail.com>]

In the scenario that you pasted, the same user did everything, which
is... pathological to an extreme. And on top of that, for the user to
mount something not in fstab, you need root which is central to
security in the first place. An insecure root account renders the
entire system easy to subvert.

In your imaginary scenario, /tmp was 0777. On every system I use, /tmp
is 1777. That sticky bit is significant.

If you try the same scenario and bob creates a directory where he is
going to mount something and Alice is going to fiendishly manipulate
the temporary mount points the moment before the mount command is
executed, then it would play out something like this:


(cynic@paranoia)(pts)(07:04pm:08/18/10)
(~)> ls -ld /tmp
drwxrwxrwt 3 root root 4096 Aug 18 19:00 /tmp
(cynic@paranoia)(pts)(07:06pm:08/18/10)
(~)> mkdir /tmp/jps
(cynic@paranoia)(pts)(07:07pm:08/18/10)
(~)> sudo su - madame.s
[sudo] password for cynic:

$ id
uid=1001(madame.s) gid=1001(madame.s) groups=1001(madame.s)
$ cd /tmp
$ ls -ld jps
drwxr-xr-x 2 cynic cynic 4096 Aug 18 19:07 jps
$ rm -rf jps	
rm: cannot remove directory `jps': Operation not permitted
$ mv jps jps2
mv: cannot move `jps' to `jps2': Operation not permitted
$ ls -ld
drwxrwxrwt 4 root root 4096 Aug 18 19:07 .

So now, if Alice has sudo, then all bets are off. But, if Alice has
sudo then the game is lost in the first place. Conversely, if Bob has
a compromised account or is afflicted with schizophrenia, all bets are
off. But neither of those cases are shortcomings of file system
permissions. The system itself will not 'let' Alice go mucking about
with Bob's files in /tmp. In fact, if Bob's umask is set to 0077, then
Alice can't even look at Bob's files or access Bob's directories.

(cynic@paranoia)(pts)(07:24pm:08/18/10)
(~)> cd /tmp/
(cynic@paranoia)(pts)(07:24pm:08/18/10)
(/tmp)> echo 'haha' > xyzzy
(cynic@paranoia)(pts)(07:23pm:08/18/10)
(/tmp)> mkdir foo
(cynic@paranoia)(pts)(07:23pm:08/18/10)
(/tmp)> ls -ld foo
drwx------ 2 cynic cynic 4096 Aug 18 19:23 foo

$ cd /tmp
$ ls -ld foo
drwx------ 2 cynic cynic 4096 Aug 18 19:23 foo
$ cd foo
cd: 3: can't cd to foo
$ cat xyzzy
cat: xyzzy: Permission denied




In closing, the synopsis from http://en.wikipedia.org/wiki/Sticky_bit

The most common use of the sticky bit today is on directories. When
the sticky bit is set, only the item's owner, the directory's owner,
or the superuser can rename or delete files. Without the sticky bit
set, any user with write and execute permissions for the directory can
rename or delete contained files, regardless of owner. Typically this
is set on the /tmp directory to prevent ordinary users from deleting
or moving other users' files. This feature was introduced in 4.3BSD in
1986 and today it is found in most modern Unix systems.


On Wed, Aug 18, 2010 at 7:03 PM, Jeremy Kister <plug-03@jeremykister.com> wrote:
> On 8/18/2010 6:56 PM, Joe Kisela wrote:
>>
>> that wouldn't work for multiple reasons. ÂYou would need permissions to
>
> I copied and pasted it from a live system.
>
>> overwrite /etc, and PAM modules in general don't follow symlinks, for
>
> as root, you have permissions to overwrite /etc.
>
> --
>
> Jeremy Kister
> http://jeremy.kister.net./
> ___________________________________________________________________________
> 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
>



-- 
J.
___________________________________________________________________________
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