Yes, the design of chroot requires it to be a privileged operation (root
user only on Unix systems, *ALLOBJ user on IBM i).
[1]
https://en.wikipedia.org/wiki/Chroot
"Only the root user can perform a chroot. This is intended to prevent
users from putting a setuid program inside a specially crafted chroot jail
(for example, with a fake /etc/passwd and /etc/shadow file) that would
fool it into a privilege escalation."
Imagine if chroot was not privileged on a platform like Linux:
- user creates a chroot tree (/my_chroot) with a specially crafted
/etc/passwd and /etc/shadow that have the root password set to "password1"
- user copies the /bin/su in to this directory tree
- user chroots in to chroot tree
- user runs su, which prompts for the password and the user enters
"password1"
- su reads from /etc/passwd and /etc/shadow (really /my_chroot/etc/passwd
and /my_chroot/etc/shadow) to validate the password
- su validates that the password matches what was in the /etc/shadow and
gives the user root authority
- *BOOM* privilege escalation
Now of course, IBM i does not use an /etc/passwd or /etc/shadow, so those
particular attacks wouldn't work. However, it would take a lot to think
through all the other possible avenues to attack.
My suggestion instead would be to build a setuid binary, which can run the
chroot command and then drop privileges to the user who ran the command.
You'd probably want to put some sort of registry or access control around
it as well, so that you can control who can access which chroots and that
people couldn't create their own chroots. (or maybe you don't care and
actually want that, idk).
So you could have a chroot.ini (chroot.json, chroot.yaml, chroot.xml,
...):
[python3]
PATH=/path/to/python3/chroot
EXEC=/bin/sh
USERS=joe bob jim
[node4]
PATH=/path/to/node4/chroot
EXEC=/bin/sh
USERS=joe jan
[run_backend]
PATH=/path/to/something/chroot
EXEC=/my/custom/command
USERS=*ALL
# As jim
$ uchroot python3
[python3] $ python3 --version
Python 3.4.4
# as jan
$ uchroot python3
Permission denied
$ uchroot run_backend
Backend processing started
Backend processing completed
$
I could write up some sample code to do that. Not sure where I'd put it,
though.
----- Original message -----
From: Aaron Bartell <aaronbartell@xxxxxxxxx>
Sent by: "OpenSource" <opensource-bounces@xxxxxxxxxxxx>
To: IBMi Open Source Roundtable <opensource@xxxxxxxxxxxx>
Cc:
Subject: Re: [IBMiOSS] Attempting chroot
Date: Wed, Jan 4, 2017 12:06 PM
The chroot command requires *ALLOBJ, unfortunately. The way around this
is
to alter the HOMEDIR attribute on your profile so that when you log in
via
ssh you will be sent directly to your chroot environment. The reason
this
latter approach works is because the SSH daemon is running as a user
with
*ALLOBJ (I am 90% sure that's the reason :-).
I've been toying with the idea of submitting an RFE to see if we can get
IBM to change the chroot permissions to only look at the new root
directory
to see if the user has permission to it. At about that time I got
distracted with looking at Docker for i.
Aaron Bartell
IBM i hosting, starting at $157/month. litmis.com/spaces
On Wed, Jan 4, 2017 at 11:53 AM, <MWHopkins@xxxxxxxxxxxxxxx> wrote:
> Hello,
>
> I'm trying to set up a chroot environment for myself on my development
> box. I followed the how_to here:
>
> /QOpenSys/QIBM/ProdData/OPS/GCC/how_to_gcc-4.6.2..txt
>
>
>
> Everything seemed to work fine setting up the chroot using a *secofr
> profile with *allobj rights, but when I try to chroot as myself I get:
>
> $ chroot /QOpenSys/mwh001 /QOpenSys/usr/bin/bsh
>
> /QOpenSys/mwh001: The file access permissions do not allow the
specified
> action.
>
>
>
> Not sure what permissions are incorrect, so I am looking for advice on
> where to go.
> I have rights to my chroot root in /QOpenSys
>
> drwxrwsrwx 9 mwh001 0 8192 Jan 04 12:14 mwh001
>
>
>
> And rights to the objects within it: /QOpenSys/mwh001
>
> drwxrwsrwx 5 mwh001 0 8192 Jan 04 12:14 QOpenSys
> lrwxrwxrwx 1 mwh001 0 34 Jan 04 10:08 bin ->
> /QOpenSys/usr/bin
> drwxrwsrwx 4 mwh001 0 8192 Jan 04 10:08 dev
> drwxr-xr-x 4 mwh001 0 8192 Jan 04 12:16 etc
> drwxrwsrwx 3 mwh001 0 8192 Jan 04 10:07 home
> lrwxrwxrwx 1 mwh001 0 34 Jan 04 10:08 lib ->
> /QOpenSys/usr/lib
> lrwxrwxrwx 1 mwh001 0 26 Jan 04 12:14 opt ->
> /QOpenSys/opt
> lrwxrwxrwx 1 mwh001 0 36 Jan 04 10:08 sbin ->
> /QOpenSys/usr/sbin
> drwxrwsrwx 2 mwh001 0 8192 Jan 04 12:14 tmp
> drwxrwsrwx 5 mwh001 0 8192 Jan 04 12:30 usr
> drwxrwsrwx 3 mwh001 0 8192 Jan 04 12:16 var
>
>
> Thanks,
>
> Matt Hopkins
> EDI/Web Services Developer
> Information Technology
> --
> Web: www.pdpgroupinc.com
> Email: MWHopkins@xxxxxxxxxxxxxxx
> Office: 410-584-0330
> Cell: 410-258-8845
> Support: EDISupport@xxxxxxxxxxxxxxx
> --
> This is the IBMi Open Source Roundtable (OpenSource) mailing list
> To post a message email: OpenSource@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: [2]
http://lists.midrange.com/mailman/listinfo/opensource
> or email: OpenSource-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at [3]
http://archive.midrange.com/opensource.
>
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [4]
http://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [5]
http://archive.midrange.com/opensource.
References
Visible links
1.
https://en.wikipedia.org/wiki/Chroot
2.
http://lists.midrange.com/mailman/listinfo/opensource
3.
http://archive.midrange.com/opensource
4.
http://lists.midrange.com/mailman/listinfo/opensource
5.
http://archive.midrange.com/opensource
As an Amazon Associate we earn from qualifying purchases.