John M Andersen wrote:

Holly cow Ted, do we have to cover a whole semester course in one email?

Jails (called chroot jails in linux) are usually for processes services and such, not for users. The FTP server might put every session in a chroot jail so that they can't get at anything else in the machine. Mail servers typically run in a jail. Users don't run in jails usually. Mostly just services.

Of course, mere mortals can't affect anything outside of areas where they have write permissions. Root, on the other hand, has free reign over the entire system and can cause a lot of damage. That's why we run as root only when necessary. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Bill Cole wrote:

On 6 Nov 2013, at 23:21, John M Andersen wrote:

...

On 11/6/2013 7:06 PM, Ted Byers wrote:

...

I was talking with a UNIX admin today about security, and he recommended a strategy involving what are temed jails on FreeBSD. He did say, he has limited experience on Suse and Ubuntu.

Holly cow Ted, do we have to cover a whole semester course in one email?

Jails (called chroot jails in linux) are usually for processes services and such, not for users. The FTP server might put every session in a chroot jail so that they can't get at anything else in the machine. Mail servers typically run in a jail. Users don't run in jails usually. Mostly just services.

Services that are supposed to be run in a Jail, are usually set up that way when you install them by yast.

Virtual machines are whole different item.

Actually, this is not true in the FreeBSD world. FreeBSD has a mature framework for implementing full system environments in jails, where all the jails and the parent host share one kernel image but each jail has its own full complement of standard services and its own IP address (in recent versions, even multiple IPs.) This makes it possible to give users their own VPS's with whatever software they need without allowing them access to the parent host or other jails but with less overhead than full virtual machines.

The closest analog for Linux is OpenVZ.

The above sounds a lot like Linux Containers too. -- Per Jessen, Zürich (4.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Nov 7, 2013 at 3:54 AM, Hans Witvliet wrote:

-----Original Message----- From: Ted Byers To: openSuSE List Subject: [opensuse] Sandboxes or jails on OpenSuse? How? Or is it possible on OpenSuse Linux Date: Wed, 6 Nov 2013 22:06:41 -0500

I was talking with a UNIX admin today about security, and he recommended a strategy involving what are temed jails on FreeBSD. He did say, he has limited experience on Suse and Ubuntu.

Hence, my question for this community.

What do security experts working on Suse (or Ubuntu if you have experience with that - I have one box running Suse and one running Ubuntu so info related to either would be useful to me).

He said the core idea is to put applications and/or users in a kind of jail, or a seriously constrained environment, so that they can do no harm to the system on which the applicatin is running, or which the user is using. This sounds like a great idea, reminiscient of the original security model Sun developed for the first Java Applets.

-----Original Message----- Hi Ted,

Remember with regards to security, there isn't a holy grail, eg a single solution that fits for all. So much I expected.

It's more like an onion, layers upon layers upon layers. And regarding weeping: all security comes at a costs, the higher lever you want, the more you have to invest in (more complicated) installation-procedure, cpu-power and user-interaction.

Perhas it would simpify things if I indicated that under no circumstances would any user be able to log into the server itself. All users, except myself, would interact ONLY with the web application. What I don't know is whether a malicious user can bypass that to hack directly into the sever itself. The admin I spoke to yesterday indicated that one of the worst offenders for opening vulnerabilitys is eval as implemented in PHP. But, not really being a PHP programmer, I do not know if that is due to sloppy PHP programming, poor design of the web application, of a defect in the PHP interpreter that in the wrong hands, gives the wrong hands access to the server's OS itself.

To be more to the point. Apparmor and selinux do provide additional security, but for for the faint-harted.

So, then,is the admin I spoke to right in saying that apparmor causes more trouble than it solves, or rather that it requires such expertise to configure correctly that it is easy to make a mistake setting it up that in turn breaks a lot of things? That is, is it a question of apparmor being bad quality, or user error, that creates the impressions of using it causing more problems than it solves.

You can separete functionalities into dedicated virtual machines. And even then, XEN provides a better isolation then LXC or KVM, but at a performance costs. And even in a VM, you can make jails.

Security is not only proper identification/authentication but much more, like availability (DOS). Some functionalities you certainly do not want to share hardware one. For instance, my CA i fon't trust to _any_ hardware, so i keep mine on a bootable stick in a vault.

And with respect to user-interaction: at one end of the spectrum you might do guest-user-accounts, single-sign-on. While at the other end, lengthy passwords for different functionalities. Multi-level authentication.

I was planning on setting up my own PKI, and having the root CA on a USB drive that is to be powered down unless I need to make a new server crt. What I would like to do, though, is set up a CA that is restricted to only signing client side certificates, but so far, I have yet to find a good resource for learning how to do this, let alone how to make the client side certificates require a password each time the user wants to use it (or even if that is possible - the idea is that once the identity of a user is veified, he gets single use credentials and uses these to access a specialized site that does nothing but create client side certificates, returning one of these, and the url so they can access the root CA's crt against which their browser can validate my server's cert - but I want the user to have to enter credentials each time the crt is used, just in case some other person gains physical access to the machine on which the client side certificate is installed). Can you point me to a resource that shows how to do this (yes, I have checked the usual sites containing documentation for openssl).

Much can/has been said/written on the subject. Too few take it seriously.

Hans --

Thanks Hans Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/07/2013 10:51 AM, Ted Byers wrote:

So, then,is the admin I spoke to right in saying that apparmor causes more trouble than it solves, or rather that it requires such expertise to configure correctly that it is easy to make a mistake setting it up that in turn breaks a lot of things?

No, he was speaking from ignorance. Apparmor can be configured from yast quite easily. And when you need to allow something that it is currently blocking there is a Generate Profile Wizard that you can use to determine just the bare minimum of what you need to enable this application, inspect exactly what Apparmor is going to allow and approve or disapprove it. It has built in profiles for almost everything you need to do on opensuse. -- Explain again the part about rm -rf / -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen wrote:

On 11/07/2013 10:51 AM, Ted Byers wrote:

...

But, not really being a PHP programmer, I do not know if that is due to sloppy PHP programming, poor design of the web application, of a defect in the PHP interpreter that in the wrong hands, gives the wrong hands access to the server's OS itself.

You can host a website without allowing ANY PHP on the site.

But PHP's vulnerability (as well as other vulnerabilities in many different web tools) is why the web server runs in a chroot jail by default on OpenSuse.

Uh, apache doesn't run in a chroot jail by default on openSUSE. -- Per Jessen, Zürich (12.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org