On Wednesday, November 06, 2013 08:21:36 PM 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?

Sure, why not? ;-) No, seriously, if the topic is that big, what would be good is a paragraph or three giving an over-view, and perhaps two or three websites, annotated as to their strengths and weaknesses. And perhaps narrow the responses to what is necessary to secure a web application, whethr created on an application server like Tomcat, or as a suite of CGI scripts that run on a web server, like Apache's httpd server, likely written in either Perl or PHP (the admin I spoke to today told me that in his view, PHP is especially vulnerable while Perl makes it much easier to develop secure web applications). I DO have a couple books I am working through, but they deal almost exclusively with modsecurity. Web application security would be in a very sad state if there existed only one useful tool for securing web applications. I don't expect all the useful information to be provided in an email, but pointers to useful, trustworthy web resources seem like a reasonable request. At this stage, while I can write my Perl code so that the application is hard to attack, I do not know what else I can add to the web server (or application server) that makes attack harder still. Nor do I know if I'd need to take additionaal measures to configure my database so that attacks become harder still. A website, or three, that gives useful details for completing the tasks that are useful, and that explains the range of issues one needs to consider.

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.

I have no intention to expose ftp or to run my own email server. (I will need to support file upload via my web application, but even there, I need to ensure that the file is a plausible size and that it does not carry a hidden threat.) My main worry is focussed on making my web applications (and of course the DB they invariably use), as secure as practicable, and using configuration practices as a complement to my usual programming practices.

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

OK, how do I tell if Apache's web server, and the Apache Tomcat application server, is set up to run in a jail? And if they aren't, can they be assigned to a jail after they're installed, and if so how?

Virtual machines are whole different item.

Except that they provide a means of isolating the server application from the hardware, and can readily be blown away and replaced, if they're compromised. Thanks Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

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.

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.

http://linuxcontainers.org/ Works very well on opensuse. -- Per Jessen, Zürich (11.8°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

Ted -- You asked about, if I read you correctly, how to protect your host and your other clients from a site being hacked. I'll say up front that I'm very much not a fan of virtual machines simply for partitioning and segregation because I *way* do not want to mess with the overhead of managine multiple OS instances; care and feeding of one is work enough without expanding by an order of magnitude. I also am not a fan of jails for the average user or process because, again, it takes work to maintain such a structure. My suggestion is to ensure that each client has - its own IP - its own user(s) - its own process(es) - its own directory tree with which to operate, thus isolating each from the other. If Customer X on IP a.b.c.X running httpd as user X in /path/to/X gets hacked (or even decides to go looking around), only content under /path/to/X is exposed and only the X httpd is compromised. Customer Y, on IP a.b.c.Y running httpd as user Y in /path/to/Y, is completely safe. You'll need to ensure that each directory tree is limited to only the relevant user & group to prevent others from wandering around via ssh, sftp, ftp or a site hack. Meanwhile, if Customer Y has a bug and locks up his httpd, Customer X is remains up & running. The best practice is to install a complete and independent copy of any application software (httpd, JRE, perl, ...) so that Customer X can configure however he wants and differently from how Customer Y does it; disk space is cheap and then you don't have to worry about conflicting modules or versions, but YMMV. Of course, all of this depends on having an IP or at least a port for each customer -- but, then again, so does the VM approach, plus with a firewall you can easily NAT & redirect traffic on your single public IP if that's your preference. As an added bonus, I not only run httpd as a distinct user but in fact as a "sub account" of the customer so that the running process only has the ability to change log files and such. Thus, Customer X has an X account which can create/maintain/destroy content & configuration files (HTML pages, JPGs, PHP code, etcetc) *and* is also a member of group "Xn", which is the primary group of a separate account Xn, which is what runs the httpd process and only has write access to log directories. Now, if the site is hacked, the worst someone can do to the local content is ... modify a log file; there's no changing of HTML pages or dropping of malware or other such. [That doesn't say, of course, that the bad guy can't also mess up the data in the DB or launch other attacks or whatnot; all of that is common to your code development no matter what account is running the web server process.] By isolating, separating, and containing each customer in this way you get very effective control and security at a very low price. Adding a new customer is as simple as making an account or two, setting up a home directory tree, and perhaps providing the standard package installs that you offer. In my corporate life, we've been doing this for about 8 years now, with a few hundred thousand web, middleware, and database "vtiers" (virtualized instances of a service tier) across about 40k servers, and we easily meet SOX, PCI, and similar control requirements. In my personal life, I even do this at home when setting up both local persistent services (samba, httpd, ...) and working on my own PHP development. Enjoy :-) HTH & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

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

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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org