Date: Tue, 14 Apr 2009 01:23:07 -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: <49E41DBB.5090805@aldan.algebra.com> In-Reply-To: <bb4a86c70904131909k44aba88dk126d25a4f1fc3744@mail.gmail.com> References: <bb4a86c70904131640n7cf471c0o7a56a43d722a90e1@mail.gmail.com> <49E3DB35.4030601@aldan.algebra.com> <bb4a86c70904131909k44aba88dk126d25a4f1fc3744@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ):
>> 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.
>
I didn't see, where you do this -- simply using mkstemp will result in
600. But it can be done, of course. However, it is still imperfect,
because all of the bluetooth users would have to be listed in obex'
group and so there can be no more than 20 of them (I think, that's the
limit on a group size).
In any case, being owned by the actual user seems far more
straightforward...
>> 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.
>From the security standpoint, this negates all/most benefits of having a
dedicated UID for the service. The security people will tell you, that,
as long as the root-owned process is always running and listening to
connections, it can some day be fooled and so they don't like it anyway.
> 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.
> also, obexapp will chroot
> into virtual root.
>
Yes, I agree, this is advantageous.
> 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 :)
>
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).
I do not think, you should give special meaning to entry named "default"
-- because that would require special handling of the case, when
somebody's BD_ADDR resolves to name "default". I'd say, it is Ok, if no
match for the device is found, to remain in the top-level directory
(after dropping the root-privileges). But, again, no strong feeling
about this.
My other ideas (such as the matching entries not necessarily being
subdirectories) came from trying to maintain compatibility with the
current operations (where everything lives in the same directory), while
still allowing the created files to belong to different, cooperating users.
> 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 agree, that continuing to run as root after accepting connection is
bad -- if a matching entry is not found, the server, indeed, ought to
setuid to some non-root user (as set by the -u switch or determined from
the ownership of the top-level itself). However, the above-mentioned
cooperation may still have its uses for some people. That said, they can
have all their BD_ADDR symlinks point to the same directory and
cooperate there, so I don't feel strongly about it either.
> 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.
>
Not sure, what "sync-ml" is (there is no such port). But what about
dropping camera's pictures and videos? People would certainly expect to
be able to do that straight from their devices (rather than by running a
client of some sort), and find the files somewhere under their home
directories (perhaps in ~/Desktop).
So, I agree with most of your change, except the UID part -- in case a
subdirectory-entry with a matching name is found, the argument of the
setuid() (and setgid()) call should be the UID (and GID) of the entry
(as determined by lstat(2), not stat(2), though).
Yours,
-mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E41DBB.5090805>