Alle 00:47, marted=EC 14 ottobre 2003, Doug Dumitru ha scritto:
> There have been a number of messages dancing around regarding
> UID/GID/permissions with hostfs.
[...] Ok, now I understood very well what you are doing.
> From my point of view, there are five options here.
> 1. Leave the hostfs UID/GID mappings as is (ie. broken). They are good
> enough to store files and boot from, although some applications seems to
Not to boot from(there are problems about this+workarounds floating).
> 2. Do a patch like I have the keeps the UID/GID "correct" thru to the
> host assuming that UML is running as root. This is a bit of a security
> risk for "untrusted" UML situations such as "mass hosting" (which is
> part of what we do).
> 3. Do patch #2 so that UML is setuid root. This is a very small amount
> better in the security department than #2, but still has a lot of
> potential "holes".
Do this. But it's not a fix for hostfs that required root UID/GID, it shoul=
be rather a fix for when you run it as root. I.e., even if you use option 5=
you still need to be careful about permissions on the host. Letting an=20
unpriviledged UML user create a root-owned file on the host is not good. Ye=
hostfs isn't something to trust, but anyway making it more secure isn't bad.
But the patch:
1) must not change anything when UML is not run as root
2) when Uml is run as root, it must also change the umask, with that of the=
current process(at least for open and creat), and also call setgroups(see=20
3) must be clean: i.e. the io calls must be surrounded by=20
functions/inlines/macros, not by the actual calls. I think that it can be=20
done easily "setuid-cleanly". Or better, the more work is for the not-setui=
case, where you must set explicitly the saved UID/GID.
4) you speak, for the SMP case, about "static data". This seems to mean you=
writing it badly.
Just add some more params to the hostfs_user relevant functions. Or better,=
avoid modifying all those params, add(inside hostfs_user) the function whic=
calls sete[ug]id + umask, taking the right params, and then call them from=
hostfs_kern in the right points(i.e., read, write and close shouldn't need=
this, but open does, if I'm not missing something great).
5) What's more, once you creat() files with right permissions and IDs, then=
there shouldn't be the need to do the seteuid calls. This because UML VFS=20
already checked permissions.
6) There is also another issue: supplementary GIDs. I.e. a file with g+w an=
GID 103, a process with 103 as supplementary group ID, might not be able to=
open the file with O_WRONLY/O_RDWR if you don't call setgroups, too(open on=
an existing file shouldn't need the ID changes, see my point 5).
> 4. Do patch #2 and build a "helper" process that is root than mangles
> file ownership externally. This is probably much harder to breach but
> might be a bit of a performance bottleneck. Implementation wise, it
> would just be a pair of pipes and an RPC across them to do the actual IO
Wouldn't this have race conditions? I.e. here you have a moment were the fi=
is created and has not get the appropriate permissions. Then, to be atomic=
inside UML, you'd probably need to lock the whole UML kernel(since any task=
could try accessing the file) and wait the helper has done its work. So, th=
isn't very good. And on the host you can try to use that file(while it's=20
owned by root) for an exploit(how to do it, but if a file was created by th=
admin then it's more trustable).
I agree that it's probably harder to breach than UML running as root, but=20
still weaker than the #5 option.
> 5. Build a "mapping layer" that stores the UID/GID external to the
> files themselves. This is what some people are talking about. There
> are a whole slew of ways to implement this, but I would vote for
> simplicity and "minimal prerequisites" over performance. A parellel set
> of directories with text files containing the UID/GID would be one
> approach. I would vote against anything that requires a formal database
> setup even though that would outperform other options.
UMSDOS already exists(but better wait for 2.6 one, since the 2.4 one just u=
8.3 host names). Let they think to performance and then use it.
> Everything here except for #2/#3 has SMP ramifications. I think that
> just seteuid/setegid will work SMP pretty much as is in that each thread
> in SMP can change independently.
You have different threads/processes inside UML, but they are mapped on few=
ones on the host. This, with 2.6 preemption, will mean you need to disable=
preemption on hostfs:
a process could be preempted after having changed id, then a 2nd proc tries=
change to another id and maybe get a refusal or looses priviledges, i.e.=20
cannot any more turn back to root id(see the real/effective/file saved ids=
semantics, I'm not checking here). But then, the 1st process is preempted=20
back and creates the file with the wrong id.
> You have to be careful how you
> transition down UID/GID structs (statics are bad) but this is probably
> I am not personally running UML SMP so I don't have a lot of
> experience here (it is just too convenient to be single-threaded).
> I am looking for some discussion here before I start up a formal patch
> set, so any input would be appreciated.
> Doug Dumitru 800-470-2756 (610-237-2000)
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729