Date: Tue, 14 Apr 2009 13:41:53 -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: <49E4CAE1.6090506@aldan.algebra.com> In-Reply-To: <bb4a86c70904140934h5b967efby4e3238bd97c5ca01@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ):
> 2009/4/13 Mikhail T. <mi+thun@aldan.algebra.com>:
>
> not really, as i said in my original email user's private obex
> directory is owned by 'obex' user, but the group is still set to the
> user's group and permissions are set to 0770.
Even if the GID of the files will be that of the user, it being owned by
obex will cause inconvenience.
> i'm having a hard time follow this part of the argument. both patches
> (yours and mine) will accept connection with elevated privileges.
> there is absolutely no difference here. so, i'm going to dismiss this
> part of the argument, sorry :)
>
You are absolutely correct, that there is no security difference between
our approaches, when a matching BD_ADDR entry is found. When one is not
found, the user to switch to can be the owner of the default/
subdirectory, for example -- I don't really care for this case.
>>> however, the process that
>>> handles the actual connection from the client is running with reduced
>>> privileges. so, there is a security benefit.
>>>
>> It will drop the root-privileges under my proposal as well. It is just
>> that the new UID will be that of the connecting user as determined by
>> the BD_ADDR match, if such a match can be found. Otherwise, yes, it
>> should become whatever user is specified with the -u switch.
>>
> if you are arguing that having separate 'obex' user provides no
> security benefits, then i disagree. and here is why.
>
> to me security is about managing the risks. i have to assume that
> someone will break into someone's system using obexapp as attack
> vector. so, lets see what happens in this case
>
> (1) when obexapp is running as separate user 'obex' in chroot()ed
> environment, the question is: what kind of damage 'obex' user can do
> in chroot()ed environment?
>
> (2) when obexapp is running as potentially _any_ user in the system in
> _unrestricted_ environment, the question is: what kind of damage _any_
> user can do while roaming free?
>
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.
>> The only thing I do feel strongly about, is that, when a matching
>> directory entry is found, the server shall perform a setuid not to the
>> generic 'obex' user, but to the owner of that entry (and chroot into it,
>> yes).
>>
>
> like i said, its security vs. usability. i probably can live with
> chroot()ing and changing uid to owner of the directory (and _not_
> symlink).
>
This is wrong. Consider:
wallaby@tasmania (11) mkdir ~/bluetooth
wallaby@tasmania (12) echo 'Please, map my ~wallaby/bluetooth to my
device' | write root
...
root@tasmania (713) ln -s ~wallaby/bluetooth
/var/spool/obex/Wallaby-Blackerry
root@tasmania (714) echo 'Done, enjoy!' | write wallaby
...
wallaby@tasmania (13) rmdir ~/bluetooth
wallaby@tasmania (14) ln -s ~wombat/bluetooth ~/bluetooh
Voila, because you trust stat(2) instead of lstat(2), Wallaby has just
gained full access to Wombat's bluetooth files -- and can switch to
anyone else's at will...
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...
> broken symlinks is a bad idea, imo. i still do not get what do you
> gain by changing ownership on files in the same directory. perhaps i'm
> missing something here. please give me an example.
>
Therein lies the problem -- the "broken symlinks" are a very useful
thing, but suffer from the negative connotations of the word "broken".
There is nothing wrong with them -- and /etc/make.conf provides a great
example. They are very convenient in that they can be read and written
in a single transaction (readlink(2) and symlink(2)) -- instead of
open(2), read(2)/write(2), close(2). Their content is immediately
readable with ls, and a directory containing them can also be modified
atomically (even from scripts: with readlink(1), rm, ln) without
locking. That's why "broken symlinks" aren't bad in general...
Now, back to the topic at hand, my plan would've been an improvement
over the current situation. Whereas the existing obexapp (and the new
one, because you insist on the new behavior being optional) would dump
everything into the same directory under the same ownership, my approach
would allow different files to belong to different users, even if they
still share the same directory.
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.
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...
So, the only thing I insist on, is that lstat be used to determine the
UID to switch to (after chroot-ing), when a matching BD_ADDR (or
bt_hostname) is found.
> like i said, its probably ok to change uid to owner of the _directory_
> and chroot() into it. but lstat(2) is out, sorry :)
>
Please, consider the above security example. stat is insecure for our
purpose, while lstat is just fine.
-mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E4CAE1.6090506>