Date: Tue, 14 Apr 2009 15:55:00 -0400 From: "Mikhail T." <mi+thun@aldan.algebra.com> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: RFC: obexapp - virtual root folder for each device Message-ID: <49E4EA14.80300@aldan.algebra.com> In-Reply-To: <bb4a86c70904141155h205b78caq95d5f2d30a583376@mail.gmail.com> References: <bb4a86c70904131640n7cf471c0o7a56a43d722a90e1@mail.gmail.com> <49E3DB35.4030601@aldan.algebra.com> <bb4a86c70904131909k44aba88dk126d25a4f1fc3744@mail.gmail.com> <49E41DBB.5090805@aldan.algebra.com> <bb4a86c70904140934h5b967efby4e3238bd97c5ca01@mail.gmail.com> <49E4CAE1.6090506@aldan.algebra.com> <bb4a86c70904141155h205b78caq95d5f2d30a583376@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ):
> something's gotta give :) can't please everybody :)
>
You can make sure, the uploaded files belong to the owner of the device,
that uploaded them.
>> I have already conceded in the previous e-mail(s), that I agree, that
>> chroot-ing into the found subdirectory is a good idea. So, it would not
>> "unrestricted" environment. The damage will be limited to the attacker's
>> full access to the user's designated subdirectory. And it will be
>> exactly the same as in your approach, because -- under your approach --
>> all of the files in the designated subdirectory will be obex-owned and
>> thus accessible to an obex' process.
>>
>
> ah, not exactly. its not only the files that 'bad guy' can upload into
> (possibly chroot()ed) environment. its the user id. for example, what
> if certain user id has access to a certain device node? 'bad guy'
> could just mknod(8) device node and ...
>
First of all, mknod(8) utility is deprecated on modern FreeBSD systems
-- in favor of devfs. So, you are worried, that a bad guy will
impersonate wallaby and access a wallaby-owned device? I don't think,
this is possible in default FreeBSD installations. And admins granting
some users direct access to devices may chose to limit remote access to
these user accounts.
> beetle# stat -L Wallaby-Blackerry
> 99 1490434 drwxr-xr-x 2 wombat wombat 5953822 512 "Apr 14 11:22:10
> 2009" "Apr 14 11:22:10 2009" "Apr 14 11:22:10 2009" "Apr 14 11:22:10
> 2009" 4096 4 0 Wallaby-Blackerry
>
> so, as you can see user/group ids are still correct, i.e. wombat/wombat.
>
Wombat UID for Wallaby-Blackberry is NOT correct!
> also i used stat -L which makes use of stat(2) instead of lstat(2). so
> from what i can see, and please feel free to correct me if i wrong,
> user wallaby just intentionally 'gave up' his/her files to user
> 'wombat'. i do not see any problem here, do you? or am i missing
> something obvious here?
>
Yes, exactly as above! User of Wallaby-Blackberry will connect and --
depending on their own choice -- have full access to Wombat's files,
because stat will tell obexapp, to use UID of wombat, whereas lstat
would've told it to use the UID of Wallaby (and fail to access Wombat's
600-moded files).
In fact, because Wallaby is free to make their own ~/bluetooth a symlink
to ANYTHING, they may get access to ANYBODY's files, even those of
users, who don't use Bluetooth. Once root sets up
/var/spool/obex/Wallaby-Blackberry pointing at /home/wallaby/bluetooth,
user Wallaby can change that link to anything -- except, perhaps, root
themselves...
>> When you use lstat, you make it root's responsibility to chown the
>> BD_ADDR-symlinks under /var/spool/obex appropriately. Root may screw it
>> up (and you may want to reject connections, if a particular entry
>> belongs to root), but using stat(2) you give them no chance...
>>
> if 'root' screws up, then game is over :) period. you can make this argument with any piece of software out there :)
>
I agree. Which is why I keep saying, you should be using lstat (to read
info on entries created by root under /var/spool/obex), instead of stat
(which would give you info on entries maintained by the -- potentially
malicious -- users).
> there probably are people who are confused about
> permission on symlink vs. permissions on the directory symlink points
> to. i was one of those people in not too distant past :-)
>
Didn't we just agree, that root being confused is a "game-over" and
shall not be mentioned?
>> That's why "broken symlinks" aren't bad in general...
>>
> ok, 'broken' symlinks are bad idea, imo, when used as access control
> mechanism :)
>
Slow, painful, but still progress... :-)
>> For example, a group of photographers dropping off pictures into the
>> common area may want to use the same server-directory. But they would
>> still prefer to be able to distinguish, who made which picture.
>>
>
> bad example - meta data in the pictures themselves tell much better story :)
>
You are nit-picking, but no, actually. The EXIF metadata (BTW, relying
on file-format specific metadata to provide information, that filesystem
itself can/should provide, seems wrong in itsefl) will give the camera's
model and the time of the shot, but not the owner... It does not matter,
again, because multiple BD_ADDR symlinks can still point to the same
directory.
>> That said, under my approach such multi-user sharing is still possible,
>> even if you insist on BD_ADDR-entries being directories:
>>
>> root@tasmania (817) mkdir /home/dropoff
>> root@tasmania (818) chmod 1777 /home/dropoff
>> root@tasmania (819) foreach cam (Wallaby Wombat Pademelon Thylacine)
>> foreach? ln -s /home/dropoff /var/spool/$cam-Camera
>> foreach? chown -h $cam /var/spool/$cam-Camera
>> foreach? end
>>
>> Under my proposal, the dropped-off pictures will belong to the proper
>> users, while all residing in the same directory (for the editors to
>> view). Under your proposal, such sharing would be far more involved to
>> set up for no extra security...
>>
>
> again, bad example, imo. all pictures will end up in /home/dropoff
> owned by the same user (either 'obex' or owner of '/home/dropoff').
>
They will under YOUR proposal (using stat). Under mine (using lstat),
the files will have different owning UIDs... Which is good :-)
You may not like a particular example, but you have to admit, that my
proposal gives more flexibility to the admin setting up BT-access. They
can, if they want to, allow meaningful directory-sharing for the files
belonging to different users. And if they don't want to, they can keep
all symlinks pointing to /home/dropoff belong to `obex' (or whoever).
Under your proposal, there is no such flexibility and yet it is not any
more secure (sorry, mknod is too superficial). Escaping from chroot is
never easy, and for non-root users it is impossible -- without bugs in
the kernel...
> just point editors to /home/dropoff instead of /var/spool/obex and be done with it.
Of course, the editors would be looking at /home/dropoff! I don't even
understand, how what I wrote could've been read differently. The editors
will be looking at /home/dropoff (or, more likely, something like
\\dropoff\dropoff\). And in there they will be able to group files by
users (owners of the matching entries under /var/spool/obex) -- if you
take my approach (lstat). Under your approach (stat), the user would be
the same (owner of /home/dropoff)...
> i also do not understand why 'sticky bit' is required (its only needed in your version of the patch).
>
It is not required -- only to prevent people from (accidentally,
perhaps) overwriting each other's files under certain circumstances.
To summarize, you seem willing to consider the owner of the matching
entry when determining, which UID to switch to when dropping
root-privileges after chroot. The only remaining disagreement is whether
to use lstat vs. stat for the purpose. It being, literally, a
one-character change in the code, you can go ahead and begin coding the
change to match your style preferences.
In the mean time, consider the example I just gave, showing stat being a
security hole...
Yours,
-mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E4EA14.80300>