* Re: [uml-devel] Exactly what is wanted with hostfs UID/GID operation
2003-10-13 22:47 [uml-devel] Exactly what is wanted with hostfs UID/GID operation Doug Dumitru
@ 2003-10-17 14:28 ` BlaisorBlade
2003-10-22 17:54 ` BlaisorBlade
1 sibling, 0 replies; 3+ messages in thread
From: BlaisorBlade @ 2003-10-17 14:28 UTC (permalink / raw)
To: user-mode-linux-devel; +Cc: jdike
Answering to a previous message of Jeff Dike
At 03:49, 11 Oct 2003, Jeff Dike wrote:
> doug@easyco.com said:
> > The code itself involves a lot of extra parameters from kernel to user
> > space as things like the current user aren't propogated down. I
> > personally think that our current patch set is "100% ugly" and would
> > not consider posting it as-is. If people are interested in
> > transparent numeric UID/GID to hostfs, then I would be happy to clean
> > up what we have and submit it.
>
> OK, that ain't the way to do it. Anything that involves passing a parallel
> set of creds through VFS will cause Al Viro to lop my head off. Since I'm
> somewhat attached to it, I will not propose such a thing, no matter how
> cleaned up it is.
I don't agree. Al Viro doesn't matter here. The only more params to pass are
from hostfs_kern.c to hostfs_user.c. Stop. Also, since we are in process
context inside hostfs_kern.c, we can also read current very easily (even if we
should rely on VFS permission handling as much as possible). By the way, if
you want to manage the UMSDOS-like db, then you need to pass exactly the same
params down.
**Security risks!**
Besides, even with the UMSDOS-like db, you still need to avoid as much as
possible to create root-owned files on the host. It's always a security risk,
even if it's not that easy to exploit: for instance, let's look at the man
page of modutils:
By default, modutils will reject attempts to use a module that
is not owned by root.
Luckily, you need write access to the /lib/modules path to exploit this, but
it's not a good thing anyway. So if we remove this possibility, it's a better
world for all us.
--
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729
EOSIGN
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [uml-devel] Exactly what is wanted with hostfs UID/GID operation
2003-10-13 22:47 [uml-devel] Exactly what is wanted with hostfs UID/GID operation Doug Dumitru
2003-10-17 14:28 ` BlaisorBlade
@ 2003-10-22 17:54 ` BlaisorBlade
1 sibling, 0 replies; 3+ messages in thread
From: BlaisorBlade @ 2003-10-22 17:54 UTC (permalink / raw)
To: user-mode-linux-devel; +Cc: Doug Dumitru
Alle 00:47, martedì 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
> complain.
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 should
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
unpriviledged UML user create a root-owned file on the host is not good. Yes,
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
below).
3) must be clean: i.e. the io calls must be surrounded by
functions/inlines/macros, not by the actual calls. I think that it can be
done easily "setuid-cleanly". Or better, the more work is for the not-setuid
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're
writing it badly.
Just add some more params to the hostfs_user relevant functions. Or better, to
avoid modifying all those params, add(inside hostfs_user) the function which
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
already checked permissions.
6) There is also another issue: supplementary GIDs. I.e. a file with g+w and
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
> operations.
Wouldn't this have race conditions? I.e. here you have a moment were the file
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, this
isn't very good. And on the host you can try to use that file(while it's
owned by root) for an exploit(how to do it, but if a file was created by the
admin then it's more trustable).
I agree that it's probably harder to breach than UML running as root, but
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 uses
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 fewer
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 to
change to another id and maybe get a refusal or looses priviledges, i.e.
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
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
> doable.
> 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)
Bye
--
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729
EOSIGN
-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply [flat|nested] 3+ messages in thread