Hardening hostfs

uml-devel Doug Dumitru 8 participants 9 messages Oct 17, 2003 – Oct 25, 2003 User-mode Linux (UML)

lore

Share & tools

lore

Doug Dumitru

author

2003-10-17 05:20 UTC #0 lore raw

I have been trying to build a reasonably bullet-proof UML kernel that prevents users from doing hostfs mounts.

I have observed some behaviours which are non ideal.

1. If hostfs is compiled in as a module, then the hostfs=... command-line arguments are not used. Thus, trying to restrict access with this does not appear to be effective.

2. If hostfs is not compiled in at all, you can still load a hostfs module assuming that you can build one off-line. This would allow a compromise of an underlying system by a "moderate" hacker with root access to the virtual.

The best that I have come up with is:

o Run UML in a chroot jail.
o Compile UML with hostfs included and not as a module
o Supply a command line ... hostfs=/doesnotexist,append when booting

I don't think that this is perfect as you could still load a LKM and probably get to the underlying filesystem. At least it is chroot'd at this point.

I have been trying to work out a way to further harden this, but there seem to be a number of stumbling blocks.

A lot of device open/close on the fly, so chrooting all of UML might be hard. The best that I can think of is to build a chroot jail with only those devices.

You still have to deal with /proc/mm for SKAS mode (at least until the next SKAS interface shift).

Signature · 19 lines

--------------------------------------------------------------------
Doug Dumitru     800-470-2756     (610-237-2000)
EasyCo LLC       [email protected]  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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Russell Coker

2003-10-17 05:56 UTC #1 lore raw

Quoted 1 line · Doug Dumitru

o Run UML in a chroot jail.

There are a variety of other security systems which UML can be run under. My SE Linux policy for UML greatly restricts which files it can access on the host (and could be made far more restrictive if you wanted to remove the xterm option).

Systrace, RSBAC, or GRSEC could also be used in a similar manner.

Signature · 16 lines

http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Peter

2003-10-17 06:14 UTC #2 lore raw

In reply to Doug Dumitru

Quoted 4 lines

I don't think that this is perfect as you could still load a LKM and probably get to the underlying filesystem. At least it is chroot'd at this point.

You can disable module support in the UML kernel.

- Peter

-------------------------------------------------------
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Geert Uytterhoeven

2003-10-17 08:30 UTC #3 lore raw

Quoted 5 lines · Peter

Quoted 3 lines
I don't think that this is perfect as you could still load a LKM and probably get to the underlying filesystem. At least it is chroot'd at this point.
You can disable module support in the UML kernel.

But you can still access /dev/mem from UML userspace and do whatever you want. I don't think you can do anything about this inside UML, only in the environment you launch UML from.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Jeff Dike

2003-10-17 13:56 UTC #4 lore raw

Quoted 2 lines · [email protected] said:

But you can still access /dev/mem from UML userspace and do whatever you want.

Not if you remove CAP_SYS_RAWIO from the bounding capability set.

Jeff

Henrik Nordstrom

2003-10-17 22:40 UTC #5 lore raw

In reply to Doug Dumitru

Quoted 8 lines · Doug Dumitru

I have been trying to build a reasonably bullet-proof UML kernel that prevents users from doing hostfs mounts.
I have observed some behaviours which are non ideal.
1. If hostfs is compiled in as a module, then the hostfs=... command-line arguments are not used. Thus, trying to restrict access with this does not appear to be effective.

There should be a module argument in this case.. but it seems there is no module arguments for the hostfs options..

Quoted 4 lines

2. If hostfs is not compiled in at all, you can still load a hostfs module assuming that you can build one off-line. This would allow a compromise of an underlying system by a "moderate" hacker with root access to the virtual.

And also in a number of other ways. This is not a question about hardening hostfs, but a question about harderning your UML environment.

Note that even if you do not have hostfs at all, the hacker can just write his own kernel module performing whatever operations on the host he likes and this will be executed as the user who runs the uml kernel on the host with the same privileges as given to the uml kernel.

There is two approaches you can take in hardening this. Which depends on your situation

a) You can hardening the UML kernel itself from user modifications. This involves disabling the support for loading kernel modules, raw I/O etc which would otherwise allow root (inside the UML) to modify the kernel operation.

b) Or you harden the environment wherein the UML kernel runs. The most common method is chrooting the UML, but as discussed in this thread a number of other options exists depending on how hard you need to have the UML isolated from the host.

Quoted 3 lines

A lot of device open/close on the fly, so chrooting all of UML might be hard. The best that I can think of is to build a chroot jail with only those devices.

There should not be many devices used by UML in a hardened setup.

Quoted 2 lines

You still have to deal with /proc/mm for SKAS mode (at least until the next SKAS interface shift).

Yes, but not really a problem is it? It is kind of just another device and you can easily mount it into the uml chroot. (see --bind option to mount)

Regards
Henrik

-------------------------------------------------------
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

BlaisorBlade

2003-10-18 13:20 UTC #6 lore raw

Alle 00:35, sabato 18 ottobre 2003, Henrik Nordstrom ha scritto:

Quoted 7 lines · Doug Dumitru

Quoted 3 lines
1. If hostfs is compiled in as a module, then the hostfs=... command-line arguments are not used. Thus, trying to restrict access with this does not appear to be effective.
There should be a module argument in this case.. but it seems there is no module arguments for the hostfs options..

As noted by Steve Schmidtke, in answer to a patch I posted about a different problem, you cannot make this an option for the module. If inside the Uml you have root access, you can even omit the option when you load the module(and to call mount you must be root anyway). So, the only right behaviour is to make the module read the option supplied at boot time.

IIRC, in the approaching 2.6 mainline kernel there is something for this purpose(I remember an article on LWN about module infrastructure changes), but I only have a very vague idea.

One solution which would work even now is to move the __uml_setup code somewhere else, and to make it conditional to CONFIG_HOSTFS(or whatever name it has): the macro is defined both if it's compiled as a module and if it's compiled statically. Then the actual module would read the external variable.

Signature · 16 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Henrik Nordstrom

2003-10-18 21:59 UTC #7 lore raw

Quoted 5 lines · BlaisorBlade

As noted by Steve Schmidtke, in answer to a patch I posted about a different problem, you cannot make this an option for the module. If inside the Uml you have root access, you can even omit the option when you load the module(and to call mount you must be root anyway). So, the only right behaviour is to make the module read the option supplied at boot time.

I don't see the point really from a security perspective, as if you can load modules you can just load whatever module you like doing whatever you like (or don't like). Nothing guarantees it is this hostfs module which checks the kernel command line.

The only valid use of the hostfs root dir option is to protect the administrator within the UML from making stupid mistakes or to simply life when the UML data is all isolated in a subtree on the host, it should not be viewed a security option providing security for the host, at least not without additional measures taken as discussed elsewhere in this thread.

Only on a strengthened UML where module loading is probidited and root does not have permission to access the kernel is this option of any security value for the host, and even then it can just as well be a plain module argument if hostfs is a module. The hostfs module then obviously needs to be loaded by controlled startup scripts within the UML before it is locked down from root, just as is the case for any other module on a secured and strengthened system.

Regards
Henrik

Michael Richardson

2003-10-25 00:44 UTC #8 lore raw

In reply to Doug Dumitru

-----BEGIN PGP SIGNED MESSAGE-----

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Doug" == Doug Dumitru <[email protected]> writes:

Doug> o Run UML in a chroot jail. o Compile UML with hostfs included and Doug> not as a module o Supply a command line
Doug> ... hostfs=/doesnotexist,append when booting

Compile without module support.
Any module you can load can do anything.

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email protected] http://www.sandelman.ottawa.on.ca/ |device driver[

] panic("Just another Debian/notebook using, kernel hacking, security guy"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP5k5/oqHRg3pndX9AQETswQAlZFN/oWzBTeG8V2pcBhL5FWJ6oaGBoUe bSQOTApjgy3nI7o7Zf3ng7MIx6B/wRvsLPmDjmKKubhkfri2Q1/25KQl5LwySrqL ULsapSwFK0hqHy/bfGbo4zbQ5r9L0i3KH/266wR0090p+NGkCcG/YITp6mckurxc GpJhqTUSLnA=
=ctBt
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel