|
By being in a chroot, no one can ever get to your database and yourI don't understand that statement. Isn't the idea of setting up an
business logic.
"environment", so that people CAN get to their databases and business logic
(through their applications)?
This is just a practical implementation of least privilege but it handles all the messy details for you. The intent is to limit the ability of a user in the environment to break out and drop into a higher privilege of access. That could affect things like DB access as well. Chrooting access still allows for access to files for serving and databases but at the proper limited access and with safeguards to limit access should the sandbox be broken out of.
You already understand how to do that in the IBM i world, chroot provides a simpler way of implementing similar security in PASE (especially when we aren't *nix geeks like Tony...)
Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
On 10/23/2015 5:52 PM, Nathan Andelin wrote:
Tony Cairns gave an awesome session on chroot. If you are runningRob,
your public facing web services on the root of your system, STOP IT!.
Just to clarify, is the warning to STOP IT because of a need to protect
PASE from being "hosed" by a user having "root" privileges?
Tony gave an awesome demo of how to create separate environments for each
developer and web services. If you get hacked, back up current chroot,
delete chroot, create a new one...
Coincidentally, this week I set up a Linux server at http://aws.amazon.com/
to use as an FTP gateway to Amazon's S3 storage, which we're interested in
using for offsite storage of our daily backups.
Of course, in a *nix world you pretty much build your application
environments by downloading useful components from repositories. I
downloaded, installed, and configured an FTP service.
However when I tried to access the service from our IBM i system, some of
the FTP commands like "mkdir" didn't work. No error messages to speak of...
I "assumed" that my FTP user profile lacked authority to the "root" file
system. I began looking for a way to grant permissions to my user ID and
came across the "visudo" command. I played with it, but being a Linux
dweeb, I pretty much hosed my Linux VM.
The best "advice" I could get from the Internet was to start over by
creating a new VM instance from a Linux image - which I did.
The real problem was that my user ID lacked privileges which are configured
in the FTP server - not really having anything to do with Linux OS
privileges.
Live and learn.
By being in a chroot, no one can ever get to your database and yourI don't understand that statement. Isn't the idea of setting up an
business logic.
"environment", so that people CAN get to their databases and business logic
(through their applications)?
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
