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>