This was going to be my orginal response to Nathan but there were
several good responses before I had a chance to post. I'll throw in my
2 1/2 cents anyway...
Thought it was obvious ....obvious to me at least. :-)
Without "locking down", "securing", "protecting" or however else you
want to conceptualize the environment a program runs in, you run risk of
allowing a user of a program to exceed the normal "boundaries" of the
program/DB interaction environment. This would be best characterized by
creating a program with *PUBLIC/*ALL authority accessing files that have
*PUBLIC/*ALL authority and running it from a command line where all the
command objects have *PUBLIC/*ALL authority. A fairly permissive
program/DB interaction environment. User in this case can be ANY
user...you have to think through the system, developer, end user
access. Everybody has access to everything.
I know you do this. I know that you know this.
Basically, you'd be nuts to run programs in an environment like this but
I have run into many shops that do run this way, supposedly
"restricting" access by assigning users to a menu at login. So although
many users may be compliant and only run what is on the menu, there
might be some that by analysis or accident end up at a command line.
Once they are on the command line, all hell can break loose: They have
escaped your "secure" environment and you have done nothing to limit the
damage when they do.
I see the same thing in web apps. The developer assumes that since the
end user is "limited" to only the web pages you have made available, the
environment is secure. But if you basically have all the files and file
systems set to *PUBLIC *ALL (or the equivalent in PASE) once they escape
your flimsy limitations, it's the wild west. They can run roughshod all
over your files and file systems. chrooting limits that by giving you
the tools to "lock down" the environment (your web pages, which is your
"sandbox" I guess). Should someone be able to exploit the environment
beyond your web pages (and there are almost limitless ways to do this),
chrooting limits the extent to which it can be done. Giving proper
access to files and file systems. I don't care if it is the developer,
user or system. YOU define the access (least privilege I hope) to each
group of users you are allowing to access the web app or command line.
You do this with your IBM i user environments already. I know you do.
chrooting helps you do this with your PASE environment, an environment
that many IBM i shops don't fully understand, not only operationally,
but from a security standpoint as well.
"Environment" is vague because you define it (end user, developer,
command line, web app, etc) "User" is vague because you define your
users and groups and access (End user, developer, system, read-only,
read/write). The "environment" is that set of programs, files, file
systems, database access, users, permissions that your users operate
in. Again, you do this on your IBM i for your RPG programs and
databases. chrooting helps you to do this in PASE (Its not limited to
PASE on IBM i, you could apply the same logic to your Linux on Power,
*NIX distros in general). It's a tool to help secure the programs you
want to run in PASE to specific operational
Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
On 10/26/2015 5:06 PM, Nathan Andelin wrote:
"This is just a practical implementation of least privilege but it handles
all the messy details for you."
"least privileges" for developers, users, or both? What messy details? Is
chroot even based on user profile?
"The intent is to limit the ability of a user in the environment to break
out and drop into a higher privilege of access."
Sorry, what kind of "user"? What kind of "environment"?
The term "break out" suggests a "sand-box" of sorts. Is chroot a way of
setting up a VM environment in PASE?
midrange.com
