[uml-devel] Exactly what is wanted with hostfs UID/GID operation

[uml-devel] Exactly what is wanted with hostfs UID/GID operation

[Doug Dumitru]

There have been a number of messages dancing around regarding 
UID/GID/permissions with hostfs.

My original message was that I had a set of patches that fixed bugs with 
UID/GID mappings when UML is run as "root".  If UML is not run as root, 
then is is impossible to create files in the hostfs area that are not 
owned by the UML "user" on the host.

The reason for my fixes was that even with UML running as "root" the 
UID/GID did not always translate down cleanly.  My "fix" was basically 
to enclose all file IO operatoins that could "create" new files or 
directories inside of seteuid/setegid calls so that UML itself became 
the user desired during the IO calls.  This seems to work well, but 
again it requires UML run as root.

Some people have talked about other ways to store UID/GID in hostfs.  I 
think this is a completely different thing.  My goal was to make the 
filesystem transparent so that UID/GID were visible and preserved 
between the host and client access points.  Other seem to want some sort 
of "mapping layer" so that the UML client "sees" UID/GID that follows 
it, but that the actual host always has a single UID.

 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.

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".

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.

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.

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 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)
EasyCo LLC       doug@easyco.com  http://easyco.com
--------------------------------------------------------------------
D3, U2, jBase Virtual Servers.    Off-site backup over the internet.
Develop/test/deploy from $20/mo.  Fast, secure, cheaper than tape.
http://mirroredservers.com        http://mirroredbackup.com



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Exactly what is wanted with hostfs UID/GID operation

[BlaisorBlade]

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

Re: [uml-devel] Exactly what is wanted with hostfs UID/GID operation

[BlaisorBlade]

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