[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: obexapp - virtual root folder for each device
- To: "Mikhail T." <mi+thun_(_at_)_aldan_(_dot_)_algebra_(_dot_)_com>
- Subject: Re: RFC: obexapp - virtual root folder for each device
- From: Maksim Yevmenkin <maksim_(_dot_)_yevmenkin_(_at_)_gmail_(_dot_)_com>
- Date: Mon, 13 Apr 2009 19:09:58 -0700
- Cc: "freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org" <freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ADkFPWeOj86Bg4KUWEiIHzIfq/poE+WAK8pbHNGIOHE=; b=lSSeQjO+7fRcTuVv70sNCXVmD/DW3MahY/jBb2P8PYrNQ9FUP7meUvvnXuyzySdpVS ZrF2KqU157m5P6yAwdLi2vKYHWJ5zFH/wdwNKcjM4NAfmw21lZDTygTEMZZBbbJrSD1I PWKq+mmzupIYC6xTs0S9OxUsz1wbuTe200GMY=
2009/4/13 Mikhail T. <mi+thun_(_at_)_aldan_(_dot_)_algebra_(_dot_)_com>:
> Maksim Yevmenkin написав(ла):
>> 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
freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe_(_at_)_freebsd_(_dot_)_org"
Visit your host, monkey.org