Date: Mon, 13 Apr 2009 19:09:58 -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: <bb4a86c70904131909k44aba88dk126d25a4f1fc3744@mail.gmail.com> In-Reply-To: <49E3DB35.4030601@aldan.algebra.com> References: <bb4a86c70904131640n7cf471c0o7a56a43d722a90e1@mail.gmail.com> <49E3DB35.4030601@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/4/13 Mikhail T. <mi+thun@aldan.algebra.com>: > Maksim Yevmenkin =CE=C1=D0=C9=D3=C1=D7(=CC=C1): >> possible setup >> >> - create 'obex' user and 'obex' group >> - create '/var/spool/obex' (or whatever you want for default root) >> owned by 'obex' user/group >> - user 'foo' creates ~/private directory under his home directory with >> 0700 permissions >> - admin setups 'obex' directory under foo's ~/private/ directory with >> 0770 permissions, this directory is owned by 'obex' user. group is set >> to foo's group >> - admin setups symlink in /var/spool/obex/ called 'foo_cell' that >> points to ~foo/private/obex >> - admin adds entry in the /etc/bluetooth/hosts file to assign >> 'foo_cell' foo's cell phone bd_addr >> - admin run obexapp server as 'obexapp -s -r /var/spool/obex -R -u obex = -C 1' >> >> every time foo's uses cell phone to send data to the obex server, the >> data will end up in foo's ~/private/obex directory. >> >> please give it a try and let me know it works. >> > I think, Maksim's proposal is suboptimal, because the uploaded files end > up owned by the new user obex, rather than the actual user (foo in the > above example), which will make file-manipulations on the system itself > more difficult (obex-owned will they not have 600 permissions?). It also permissions on files will be set to 0660. > necessitates creation of a new UID without the security benefit of > having the daemon run under that UID permanently (but only switching > after accepting each connection)... i beg to differ. main process (the one that accepts connection) is running with elevated privileges, yes. however, the process that handles the actual connection from the client is running with reduced privileges. so, there is a security benefit. also, obexapp will chroot into virtual root. > My proposal -- discussed with Maksim at length -- would *derive the > user-ID from the ownership of the link*. The sample set up would then be > as follows. Suppose, user named wallaby has a device with BD_ADDR > 01:02:03:04:05:06. The user would create a subdirectory for their > bluetooth files (or use something existing, like ~/Desktop/): as i tried to explain, there are few problems (imo) with your patch. one example: what happens when remote client decides to create a directory which matches another client's bd_addr or name? i also do not like the fact that client are allowed to "escape" from their virtual root directory. another thing is that you pretty much force new behavior and not giving any control to disable it. what is worse, new behavior is controlled by file system elements which remote clients can potentially see, create and/or modify. [...] > My proposal has other, not so significant differences -- it allows the > BD_ADDR-entries in /var/spool/obex to be non-directories (files, broken > links a'la /etc/make.conf, even sockets). Even if a chdir into such an > entry fails, the ID of the entry's owner will still be used to > determine, which user shall own any uploaded files, etc. even though all > such files will end up in the same directory (as they do with the > current version of obexapp). > > Maksim thought, offering such flexibility would be too confusing... please explain what does it buy you exactly? so, great, you can control file ownership in the _same_ directory. like i said, unless you set sticky bit on the directory (which is evil, imo) and make it 0777 there is still a problem with sharing files (either obexapp running under new id won't be able to write to the root directory or everybody will be able to delete each others files). either way, its not that different from what obexapp does right now. > I agree, that chroot-ing (rather than merely chdir-ing) into such a > "virtual root" directory makes sense. The only material difference > between our proposals is my deriving the desired UID from the ownership > of the found BD_ADDR entry vs. Maksim's always using the user specified > on command-line (such as 'obex'). i'm actually not feeling very strongly about this. my initial choice is to be on a safe side. basically, what i'm trying to guard against is when someone put a symlink owned by root into the obexapp root folder. this is very easy thing to do, imo. i personally did it :) basically this type of misconfiguration will make obexapp continue to run with elevated privileges while servicing clients requests and that is a 'bad thing (tm)' :) i also must say that we are trying to solve the problem at the wrong level. more specifically, for phone book back up you probably want to use something else (like sync-ml for example) not not obexapp. bluetooth obex profiles are just completely oblivious to the fact that clients might need to supply credentials. its all strictly personal. so what i did, it basically provided mechanism to extend it in a similar manner. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70904131909k44aba88dk126d25a4f1fc3744>