Date: Tue, 14 Apr 2009 11:55:04 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: RFC: obexapp - virtual root folder for each device Message-ID: <bb4a86c70904141155h205b78caq95d5f2d30a583376@mail.gmail.com> In-Reply-To: <49E4CAE1.6090506@aldan.algebra.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>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/4/14 Mikhail T. <mi+thun@aldan.algebra.com>: > Maksim Yevmenkin =CE=C1=D0=C9=D3=C1=D7(=CC=C1): >> 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. something's gotta give :) can't please everybody :) [...] >>>> 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. 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 ... >>> 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... hmm.... perhaps, i'm missing something here. here is what i did =3D=3D step 1 =3D=3D %id uid=3D1004(wallaby) gid=3D1004(wallaby) groups=3D1004(wallaby) %mkdir ~/bluetooth %ls -l drwxr-xr-x 2 wallaby wallaby 512 Apr 14 11:20 bluetooth =3D=3D step 2 =3D=3D beetle# pwd /var/spool/obex beetle# ln -s ~wallaby/bluetooth Wallaby-Blackerry beetle# ls -l lrwxr-xr-x 1 root obex 23 Apr 14 11:21 Wallaby-Blackerry -> /home/wallaby/bluetooth beetle# stat -L Wallaby-Blackerry 99 1490343 drwxr-xr-x 2 wallaby wallaby 5953437 512 "Apr 14 11:20:37 2009" "Apr 14 11:20:37 2009" "Apr 14 11:20:37 2009" "Apr 14 11:20:37 2009" 4096 4 0 Wallaby-Blackerry so as you can see user/group ids are correct, i.e. wallaby/wallaby =3D=3D step 3 =3D=3D %id uid=3D1005(wombat) gid=3D1005(wombat) groups=3D1005(wombat) %mkdir ~/bluetooth %ls -l drwxr-xr-x 2 wombat wombat 512 Apr 14 11:22 bluetooth =3D=3D step 4 =3D=3D %id uid=3D1004(wallaby) gid=3D1004(wallaby) groups=3D1004(wallaby) %pwd /usr/home/wallaby %rmdir bluetooth/ %ln -s ~wombat/bluetooth ~/bluetooth %ls -l lrwxr-xr-x 1 wallaby wallaby 22 Apr 14 11:29 bluetooth -> /home/wombat/bluetooth =3D=3D step 5 =3D=3D beetle# pwd /var/spool/obex 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. 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? > 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 :) >> 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 please let it go already :) i heard your point about /etc/malloc.conf several times. you made it loud and clear. just because someone did it this way, does not mean the the same model should be applied for everything else. i'm sure whoever did this had good reasons for doing it this way. keep in mind that someone else (or possibly the same person) provided MALLOC_OPTIONS environmental variable and _malloc_options global variable to override /etc/malloc.conf. imo, its fine to use 'broken' symlinks to pass a few characters, however, you suggesting to use the same model for something that is more complicated. 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 :-) > 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... ok, 'broken' symlinks are bad idea, imo, when used as access control mechanism :) > 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. bad example - meta data in the pictures themselves tell much better story := ) > 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'). just point editors to /home/dropoff instead of /var/spool/obex and be done with it. the only difference is that all the files will be owned by the same user, but like i said, meta data in the pictures will tell far better story then user id :) i also do not understand why 'sticky bit' is required (its only needed in your version of the patch). > 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. please see my example above. >> 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. hmm, for my example above beetle# stat Wallaby-Blackerry 98 47348 lrwxr-xr-x 1 root obex 1836017711 23 "Apr 14 11:21:23 2009" "Apr 14 11:21:23 2009" "Apr 14 11:21:23 2009" "Apr 14 11:21:23 2009" 4096 0 0 Wallaby-Blackerry and (with trailing /) beetle# stat Wallaby-Blackerry/ 99 1490343 lrwxr-xr-x 1 wallaby wallaby 1836017711 22 "Apr 14 11:29:08 2009" "Apr 14 11:29:08 2009" "Apr 14 11:29:08 2009" "Apr 14 11:29:08 2009" 4096 0 0 Wallaby-Blackerry/ stat(1) _without_ '-L' option uses lstat(2). thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70904141155h205b78caq95d5f2d30a583376>