Re: [IBMiOSS] Attempting chroot -- OPENSOURCE

I could write up some sample code to do that. Not sure where I'd put it,

though.

Maybe do a new dir in https://bitbucket.org/litmis/portlibfori ? Not
exactly a "port", but close enough? :-)

The other way to look at this is from the standpoint of one of the core
premises of how ibmichroot is being used as of late; specifically as a poor
mans container. Containers are often used for development, testing and
production scenarios. The concept of containers usually has a focus on
automation; including generating a user profile that is used within the
container.

Following the above logic, and given chroot only works in PASE, it would
make sense to generate new users with the HOMEDIR of their *USRPRF set to
the new chroot. Or maybe better stated (and this is my opinion): chroot is
operating as it should and automation should be used to address this
dilemma. This is one of the reasons I can't (yet) do an RFE for
something like this.

If you were taking votes for how you should allocate your highly valued
time; I'd rather have it put towards porting Go-lang so we could eventually
get a partial implementation of Docker working on i; similar to how Windows
has a partial implementation of Docker (because it lacks features like
cgroups). Man, that was an awesome run-on sentence. TWO semi-colons!

Aaron
"winning at run-on since 1985"
Bartell
IBM i hosting, starting at $157/month. litmis.com/spaces

On Wed, Jan 4, 2017 at 1:40 PM, Kevin Adler <kadler@xxxxxxxxxx> wrote:

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
--
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: http://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/opensource.