Very Computer

Is there a way to mount an already mounted filesystem using the
bind mount procedure by referencing the filesystem using a device?

Here's my idea:

Linux boots up with hda1 mounted as / and runs a custom init.
Some processes may be started at this point, or maybe not.
A 2nd filesystem, hda2, will be mounted at (the arbitrarily
chosen path of) /sys.  The 2nd filesystem (with whatever else
gets mounted within there) is a complete run-time system.
The modified init will read /sys/etc/inittab and for every
process started according to that inittab, it will chroot()
the child to /sys before execve()-ing the specified program.
With /sys/etc/inittab being the startup for a complete system,
that system will really be running in the chroot context.
What few processes run in the original root context would be
restricted to doing things more securely, such as not running
servers which might be exploitable (this might mean running
nothing at all).

The question is whether, if a root process running in the hda2
context is exploited and totally controlled, can it then mount
hda1 some way to bypass the chroot barrier?

What I've tried so far suggests the answer might be "no".  But
I cannot be sure I have tried everything (a common problem in
security analysis).  So I'm hoping someone who has a better
understanding of how bound mount works (or at least is supposed
to work) might have some insight into this.

I've also considered using pivot_root(), but that ends up with
the original root being a subdirectory of the new root, and is
thus not really secure.  I could then unmount the original root,
but then it can be mounted again by having a device node for
the original filesystem.  So I think chroot() while keeping the
original root mounted (to prevent further mounting as long as
bind mount doesn't leak this) might make this more secure.

Of course it might be possible to write on the device itself.
But I think this can be more easily addressed.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------

Yes, just mount the device again on a different mount point
with same options as the existing mount. If an inode for
/dev/hda1 exist within the chroot, it can be mounted on a
directory inside. The mount will only succeed if the same
options are used. From the kernels point of view there is
no different from mounting the device twice and creating a
bindmount of the root of that filesystem. But the entries
created by mount in /etc/mtab will look slightly different.
And in my experience bindmounting the root of one filesystem
to another location can confuse startup scripts, fsck, and
mount. OTOH mounting the device multiple times works without
a glitch. Bindmounting a subdirectory of a filesystem does
not cause problems which is very fortunate, because that
could not have been done by just mounting the device
multiple times.

Quote:

> What I've tried so far suggests the answer might be "no".

What did you try? Did you try to mount /dev/hda1 again on
another mountpoint? If you did try that, what happened?

Quote:

> I've also considered using pivot_root(), but that ends up with
> the original root being a subdirectory of the new root, and is
> thus not really secure.  I could then unmount the original root,
> but then it can be mounted again by having a device node for
> the original filesystem.  So I think chroot() while keeping the
> original root mounted (to prevent further mounting as long as
> bind mount doesn't leak this) might make this more secure.

Well, chroot was never intended to be a security feature.
It can be handy in a lot of system maintainance. But with
root permitions it is trivial to break out of a chroot. I
don't think mounting the real root on another mount point
is the most often suggested way to escape, but it is a way.

Other ways include doing one more chroot to make the first
no longer a root and thus allowing to escape with chdir("..");
communicating with processes outside the chroot, and finally
messing around with kernel data structurees.

I think what you really want is not a chroot, but rather a
jail. Some version of BSD has a jail. There is being worked
on some jail system call for Linux, but I don't know how
serious the efforts are. Take a look on the kernel mailing
list, AFAIR some patches were posted.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

It most certainly can - without --bind.  Just mount it.

_Any_ security ends when attacker gains control over root process.
Don't fool yourself - there are hundreds ways to*the system
once that happens and all schemes based on assumption that root
can be contained are doomed.

In particular, setup you'd described won't hold root regardless of mount(2)
behaviour - mkdir /foo && chdir /foo && chroot ../.. && chdir /  will happily
take root process out of chroot jail.  End of story.

And that's the simplest way of getting to the stuff outside of chroot tree -
there is a lot of other methods.

--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

Ugh,
                           chroot /foo && chdir .. && chroot .
sorry - a braino.

--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

|> What I've tried so far suggests the answer might be "no".
|
| What did you try? Did you try to mount /dev/hda1 again on
| another mountpoint? If you did try that, what happened?

My mistake was I was doing -o bind (or --bind) and thinking that was
the means to get a filesystem munted twice.  But being as you can mount
it again by referencing the device (I had a case fail, but I don't
recall why, now) then it would be trivial to mknod and mount to get out
of chroot (if everything is r/o, do mount tmpfs before that).

Out of curiosity, the new 2.4.19 has two / filesystems:

rootfs / rootfs rw 0 0
/dev/root / reiserfs rw 0 0
proc /proc proc rw 0 0
[...]

How might I go about accessing that _first_ one?  I read in source
where "rootfs" is just an alias for ramfs.  But I don't see any
particular use of it being made.

| I think what you really want is not a chroot, but rather a
| jail. Some version of BSD has a jail. There is being worked
| on some jail system call for Linux, but I don't know how
| serious the efforts are. Take a look on the kernel mailing
| list, AFAIR some patches were posted.

I already looked at vserver, for example.  It isn't what I need.  I did
read some about BSD jail, and it, too, seemed to be more restrictive.
I want an environment that _can_ do just about everything _except_
modify a particular filesystem (the one that holds the kernel and is
mounted as root).  For example, vserver limits each context to doing a
single IP address.  I want an environment that looks like it is a whole
complete running system, but that there is in fact something else
running that cannot be seen.  I'm not looking to isolate processes from
each other as jail/vserver might normally be used for.  Think of vmware
but without the overhead and with the host environment having full
shared filesystem access to the guest.

If the new jail work for Linux can let anything run except what is
explicitly excluded, then maybe that would work.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------

|>The question is whether, if a root process running in the hda2
|>context is exploited and totally controlled, can it then mount
|>hda1 some way to bypass the chroot barrier?
|
| It most certainly can - without --bind.  Just mount it.

Oops.  Somehow I totally missed that.  Something in my brain thinks I have
gotten "filesystem already mounted" error.  Maybe that was with an older
kernel.

| _Any_ security ends when attacker gains control over root process.
| Don't fool yourself - there are hundreds ways to*the system
| once that happens and all schemes based on assumption that root
| can be contained are doomed.

What I'm looking to do is have an isolated group of processes which
are the ones that started the system, which the normally running root
processes have no way to get to (as long as the kernel is secure).
I most particularly want to make sure that the logic that starts the
system up cannot be modified by the running system.  Currently I do
this by booting from CDROM and mounting the CDROM as root.  But CDROM
devices are flimsy and unreliable for heavy use, and take up a drive
bay.  So I'm looking for an alternative based on a hard drive.

I'm thinking if there is a way to effectively lock out a partition
(and the whole disk) so that there is no access to it except from
a certain group of processes (the ones that aren't in chroot, for
example), I can get the same effect as the unwriteable CDROM.

| In particular, setup you'd described won't hold root regardless of mount(2)
| behaviour - mkdir /foo && chdir /foo && chroot ../.. && chdir /  will happily
| take root process out of chroot jail.  End of story.

|
|>In particular, setup you'd described won't hold root regardless of mount(2)
|>behaviour - mkdir /foo && chdir /foo && chroot ../.. && chdir /  will happily
|
| Ugh,
|                           chroot /foo && chdir .. && chroot .
| sorry - a braino.

Trying this, I still get "chdir .." putting me back in the current root
and not escaping from the chroot.  I don't doubt there can be a way,
but this isn't doing it.  It does appear to be properly faking ".." for
the current root be the same as "." instead of going to its real parent.
Even the file listing shows ".." and "." having the same inode number.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://www.veryComputer.com/|

-----------------------------------------------------------------

This should be coming in the next version of Linux.  FreeBSD has some
minimal coarse support for doing what you want, and I believe work is
being done to improve that as well.  I'm not aware of anything being
done with e.g. OpenBSD but it wouldn't surprise me.

Actually, there are probably about 5 different families of kernel
patch to give you about the functionality you want, SELinux being the
most paranoid of the bunch.

[...]

Quote:> Trying this, I still get "chdir .." putting me back in the current root
> and not escaping from the chroot.  I don't doubt there can be a way,
> but this isn't doing it.  It does appear to be properly faking ".." for
> the current root be the same as "." instead of going to its real parent.
> Even the file listing shows ".." and "." having the same inode number.

From FreeBSD's chroot(2):

     Depending on the setting of the `kern.chroot_allow_open_directories'
     sysctl variable, open filedescriptors which reference directories will
     make the chroot() fail as follows:

     If `kern.chroot_allow_open_directories' is set to zero, chroot() will
     always fail with EPERM if there are any directories open.

     If `kern.chroot_allow_open_directories' is set to one (the default),
     chroot() will fail with EPERM if there are any directories open and the
     process is already subject to a chroot() call.

     Any other value for `kern.chroot_allow_open_directories' will bypass the
     check for open directories

My initial motivation for including that was that your kernel might do
the same thing, but upon further reflection, I seem to remember the
Linux crowd strenuously objecting to the above "solution."  But I can
no longer find any information on the subject, so I guess I'm just
including it in the interests of completeness.

Oh, and the chroot tricks don't work for me either.

--

"Last I checked, it wasn't the power cord for the Clue Generator that
was sticking up your ass." - John Novak, rasfwrj

| Actually, there are probably about 5 different families of kernel
| patch to give you about the functionality you want, SELinux being the
| most paranoid of the bunch.

And SELinux brings along a lot of baggage I don't want.  IMHO, making
a system impossible to manage defeats security.

| From FreeBSD's chroot(2):
|
|     Depending on the setting of the `kern.chroot_allow_open_directories'
|     sysctl variable, open filedescriptors which reference directories will
|     make the chroot() fail as follows:
|
|     If `kern.chroot_allow_open_directories' is set to zero, chroot() will
|     always fail with EPERM if there are any directories open.
|
|     If `kern.chroot_allow_open_directories' is set to one (the default),
|     chroot() will fail with EPERM if there are any directories open and the
|     process is already subject to a chroot() call.

I don't see the point of this.  chroot() will be done before root is given
up, so if there is anything present that would defeat the chroot(), then the
process run take care of it.  If it's already compromised by this point in
time, the battle is lost anyway.

| My initial motivation for including that was that your kernel might do
| the same thing, but upon further reflection, I seem to remember the
| Linux crowd strenuously objecting to the above "solution."  But I can
| no longer find any information on the subject, so I guess I'm just
| including it in the interests of completeness.

I don't see how it is a solution to anything.  What's the problem?  What
do open directories have to do with anything?  I understand one could do
fchdir() on an open directory and escape.  Whoever is doing chroot()
needs to not have them.  Now a non-root variant of chroot() is something
altogether different, and would have to have a lot of restrictions and
tests.  I'd rather not have a non-root chroot(), anyway.  But I don't
know if that's what you meant or not.

In addition to chroot(), there should be a way to have a process give up
the ability, for itself and all its descendents, to do a number of things,
even if root, such as opening device nodes (but it still gets to create
them in filesystems/directories it has write/create access to), binding
socket ports less than 1024, binding raw sockets, and even writing to files.
Hopefully these are the kinds of things the Linux jail people are working
on.

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------

It doesn't really make it impossible to manage.  And SELinux is only
the most paranoid; there may be something else that works as you wish
it to.

Quote:> | From FreeBSD's chroot(2):
> |     Depending on the setting of the `kern.chroot_allow_open_directories'
> |     sysctl variable, open filedescriptors which reference directories will
> |     make the chroot() fail as follows:
> |     If `kern.chroot_allow_open_directories' is set to zero, chroot() will
> |     always fail with EPERM if there are any directories open.
> |     If `kern.chroot_allow_open_directories' is set to one (the default),
> |     chroot() will fail with EPERM if there are any directories open and the
> |     process is already subject to a chroot() call.
> I don't see the point of this.  chroot() will be done before root is given
> up, so if there is anything present that would defeat the chroot(), then the
> process run take care of it.  If it's already compromised by this point in
> time, the battle is lost anyway.

Presumably kern.chroot_allow_open_directories is only changeable when
the system is in insecure mode, though I can't say for sure.

Quote:> | My initial motivation for including that was that your kernel might do
> | the same thing, but upon further reflection, I seem to remember the
> | Linux crowd strenuously objecting to the above "solution."  But I can
> | no longer find any information on the subject, so I guess I'm just
> | including it in the interests of completeness.
> I don't see how it is a solution to anything.  What's the problem?  What
> do open directories have to do with anything?  I understand one could do
> fchdir() on an open directory and escape.  Whoever is doing chroot()
> needs to not have them.  

The current directory is always open, and

     It should be noted that chroot() has no effect on the process's current
     directory.

Obviously any sane chroot(8) is going to chdir(new_root) first, but
perhaps this is intended more to deal with programs which
(incorrectly) don't.  That would certainly explain the Linux crowd's
resistance to an option like this (fix the broken code, don't put a
hack in the kernel to work around it!).

But again, I can't find any of the discussion on this, so don't take
my rationalizing as TRVTH.

[...]

Quote:> In addition to chroot(), there should be a way to have a process give up
> the ability, for itself and all its descendents, to do a number of things,
> even if root, such as opening device nodes (but it still gets to create
> them in filesystems/directories it has write/create access to), binding
> socket ports less than 1024, binding raw sockets, and even writing to files.
> Hopefully these are the kinds of things the Linux jail people are working
> on.

I'd prefer making those changes system-wide.  Just block the "new"
calls, e.g. open(), bind(), and so on.

X would be the sore spot there, I suspect.  But we already know better
than to run X on a secure system, so perhaps it wouldn't matter.

--

"Last I checked, it wasn't the power cord for the Clue Generator that
was sticking up your ass." - John Novak, rasfwrj

Did you try doing it using a C program or some kind of shell
script? I don't think you can do it with a shell script, but
with a C program that in the end execve /bin/sh, it should work.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

Mount will usually complain about mounting the same filesystem twice on
the same mount point.

Quote:> system up cannot be modified by the running system.  Currently I do
> this by booting from CDROM and mounting the CDROM as root.  But CDROM
> devices are flimsy and unreliable for heavy use, and take up a drive
> bay.  So I'm looking for an alternative based on a hard drive.

> I'm thinking if there is a way to effectively lock out a partition
> (and the whole disk) so that there is no access to it except from
> a certain group of processes (the ones that aren't in chroot, for
> example), I can get the same effect as the unwriteable CDROM.

Get a hard disk with write protect jumper.

--
M?ns Rullg?rd

Are they all safe, or can some of them by bypassed by software?

This reminds me about something I recently read on slashdot
about floppies, a lot of people claimed that the writeprotection
on floppies was implemented in software. Is that really true,
and if so, what do I need to change in my kernel to write to a
writeprotected floppy?

--
Kasper Dupont -- der bruger for meget tid p? usenet.

That's the problem when everything is so secret...

Quote:> This reminds me about something I recently read on slashdot
> about floppies, a lot of people claimed that the writeprotection
> on floppies was implemented in software. Is that really true,
> and if so, what do I need to change in my kernel to write to a
> writeprotected floppy?

Who cares about floppies these days?  Stick with CDs if you want
removable read-only media.

--
M?ns Rullg?rd

I do, if the machine I'm using doesn't have a CD-R :-)  Anyways,
Kasper likely doesn't really care about actual use here..  like
most of us, he probably just wants to hack.

--
 Joshua Jones
 josh(at)homemail.com  |  jonesjos(at)us.ibm.com

That is true, but I can think of more interesting hacking projects than
writing to write protected floppies...

--
M?ns Rullg?rd