Date: Tue, 14 Apr 2009 09:34:43 -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: <bb4a86c70904140934h5b967efby4e3238bd97c5ca01@mail.gmail.com> In-Reply-To: <49E41DBB.5090805@aldan.algebra.com> References: <bb4a86c70904131640n7cf471c0o7a56a43d722a90e1@mail.gmail.com> <49E3DB35.4030601@aldan.algebra.com> <bb4a86c70904131909k44aba88dk126d25a4f1fc3744@mail.gmail.com> <49E41DBB.5090805@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):
>>> I think, Maksim's proposal is suboptimal, because the uploaded files en=
d
>>> 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 als=
o
>>>
>> 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,
perhaps you should take a closer look at the patch i posted? :-) in server.=
c
@@ -565,6 +668,15 @@
}
}
+ if (chmod(context->temp, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP) < 0) {
+ log_err("%s(): Could not chmod(%s). %s (%d)",
+ __func__, context->temp,
+ strerror(errno), errno);
+
+ codes =3D obexapp_util_errno2response(errno);
+ goto done;
+ }
+
> 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).
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.
> In any case, being owned by the actual user seems far more
> straightforward...
its all about security vs. usability to me :) please read below.
>>> 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.
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 :)
>> 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?
keep in mind that 'bad guy' can populate his environment with all kind
of files before obtaining shell.
now, please put on your security person's hat and tell me honestly
which option would you choose?
>> 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).
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).
> 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.
i'm willing to take my chances of this one :) its strictly local
configuration and if someone has, in fact, named his/her bluetooth
gadget 'default' then its too bad :) i'm also not keen of keeping
'default' name. it can be anything, like '00:00:00:00:00:00' or
whatever.
> 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 user=
s.
no, just put new behavior under separate option and keep it disabled
by default.
>> 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.
the 'default' virtual root stays. remote clients have no business to
see, know about and/or try to mess with other clients virtual roots.
not sure if you noticed, but 'default' virtual root can be also
considered as another level of access. basically, if there is no
'default' virtual root, clients without virtual root won't be able to
access the server.
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.
>> 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
there is something called multisync (or something like that) but it
needs freebsd bluetooth plugin. basically sync-ml is a xml based
protocol that runs over obex and is used for synchronizing objects on
systems.
> 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).
sure and they can do it.
> 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).
like i said, its probably ok to change uid to owner of the _directory_
and chroot() into it. but lstat(2) is out, sorry :)
thanks,
max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70904140934h5b967efby4e3238bd97c5ca01>