Hi all,
Two questions
1. According to http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU?highlight=%28xen%29 it would be /srv/xen or even /var/lib/xen/images.
¿What is the correct absolute path to put into the xen domains files?
2. Moreover, if you want the domU(s) boot together dom0, you should put the domains files (images) into /etc/xen/auto.
¿A simple symlink will be enough in this case?
On Mon, 2007-06-18 at 11:50 +0200, Jordi Espasa Clofent wrote:
- According to
http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU?highlight=%28xen%29 it would be /srv/xen or even /var/lib/xen/images.
¿What is the correct absolute path to put into the xen domains files?
Whatever you prefer, as long as the images have the correct security context. Otherwise, SELinux will deny access to the images.
- Moreover, if you want the domU(s) boot together dom0, you should put
the domains files (images) into /etc/xen/auto.
¿A simple symlink will be enough in this case?
No, you shouldn't put the images there, but the (Xen) domain configuration files of the domains you would like to start during the boot process.
-- Daniel
Daniel de Kok wrote:
On Mon, 2007-06-18 at 11:50 +0200, Jordi Espasa Clofent wrote:
- According to
http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU?highlight=%28xen%29 it would be /srv/xen or even /var/lib/xen/images.
¿What is the correct absolute path to put into the xen domains files?
Whatever you prefer, as long as the images have the correct security context. Otherwise, SELinux will deny access to the images.
- Moreover, if you want the domU(s) boot together dom0, you should put
the domains files (images) into /etc/xen/auto.
¿A simple symlink will be enough in this case?
No, you shouldn't put the images there, but the (Xen) domain configuration files of the domains you would like to start during the boot process.
As Daniel said it the config file that goes in /etc/xen/auto, but you can also symlink to the config file, not the image.
My preference was to use /srv/xen and then symlink /srv/xen/etc to /etc/xen and /srv/xen/images to /var/lib/xen/images
YMMV, Rick
On Mon, Jun 18, 2007 at 11:05:24AM -0400, Rick Barnes wrote:
My preference was to use /srv/xen and then symlink /srv/xen/etc to /etc/xen and /srv/xen/images to /var/lib/xen/images
My preference is to disable SELinux totally and use /xen as a seperate mount point :-)
Which I would be using now except I read that VMware server doesn't work on a Xen kernel, so that ruins that!
On Mon, 2007-06-18 at 11:07 -0400, Stephen Harris wrote:
On Mon, Jun 18, 2007 at 11:05:24AM -0400, Rick Barnes wrote:
My preference was to use /srv/xen and then symlink /srv/xen/etc to /etc/xen and /srv/xen/images to /var/lib/xen/images
My preference is to disable SELinux totally and use /xen as a seperate mount point :-)
I keep repeating in a sheepish fashion: baaaaad :p.
-- Daniel
On Mon, Jun 18, 2007 at 05:46:27PM +0200, Daniel de Kok wrote:
On Mon, 2007-06-18 at 11:07 -0400, Stephen Harris wrote:
On Mon, Jun 18, 2007 at 11:05:24AM -0400, Rick Barnes wrote:
My preference was to use /srv/xen and then symlink /srv/xen/etc to /etc/xen and /srv/xen/images to /var/lib/xen/images
My preference is to disable SELinux totally and use /xen as a seperate mount point :-)
I keep repeating in a sheepish fashion: baaaaad :p.
I've not heard a good reason to keep SELinux enabled, to be honest. For high sensitivity stuff, sure (much like using SEOS on Solaris for high sensitivity machines - eg those where third parties might have access). But as a general rule for all machines? Why?
Being sheep like doesn't educate; a sheeplike post is... pointless.
On 6/18/07, Stephen Harris lists@spuddy.org wrote:
On Mon, Jun 18, 2007 at 05:46:27PM +0200, Daniel de Kok wrote:
On Mon, 2007-06-18 at 11:07 -0400, Stephen Harris wrote:
On Mon, Jun 18, 2007 at 11:05:24AM -0400, Rick Barnes wrote:
My preference was to use /srv/xen and then symlink /srv/xen/etc to /etc/xen and /srv/xen/images to /var/lib/xen/images
My preference is to disable SELinux totally and use /xen as a seperate mount point :-)
I keep repeating in a sheepish fashion: baaaaad :p.
I've not heard a good reason to keep SELinux enabled, to be honest. For high sensitivity stuff, sure (much like using SEOS on Solaris for high sensitivity machines - eg those where third parties might have access). But as a general rule for all machines? Why?
Being sheep like doesn't educate; a sheeplike post is... pointless.
Ok.. I have had good and bad experience with Selinux.
Good experience... I have had multiple webservers not have successful exploits because someone forgot to update phpBB or some such. Another good experience was dealing with a mail server compromise that didnt happen (it looked like it had but selinux had stomped the bad program when it tried to execute.)
Bad experience... spending 8 hours because of a broken shipped policy that I needed to find a posting on to fix. Or trying to figure out why xen on my test system wasnt working because selinux policy doesnt do what it says it is supposed to do.
However, overall I have found that spending 8-12 hours to read/learn Selinux was worth it. I believe that it and the SuSE tool are pretty much going to be needed in the future as Linux become more popular and hacking/breaking into it is more monetarily worthwhile to the mobs etc.
Yes they add complexity.. but I am old enough to remember having to deal with people who thought that the Unix DAC rwx system was too complicated. Heck it was only 2 years ago I had to figure out what/why a system was compromised.. the reason was that the person was an NT person and had set everything on the system as 7777 that he could.. so that he didnt have to remember root passwds and all his applications just worked. [Effectively turning off Unix DAC as it were.]
What I normally do is build system first with a default policy in place.. and if I cant figure out or have other issues.. I put selinux in permissive mode to work from there.
On Mon, Jun 18, 2007 at 10:31:30AM -0600, Stephen John Smoogen wrote:
On 6/18/07, Stephen Harris lists@spuddy.org wrote:
I've not heard a good reason to keep SELinux enabled, to be honest. For high sensitivity stuff, sure (much like using SEOS on Solaris for high sensitivity machines - eg those where third parties might have access). But as a general rule for all machines? Why?
Good experience... I have had multiple webservers not have successful
Yup. Webservers are machines where third parties might have access, and so are candidates for enhanced security processes such as SELinux or SEOS.
I've never said there are _no_ cases for SELinux. I was questioning it as a general rule for all machines.
On 6/18/07, Stephen Harris lists@spuddy.org wrote:
On Mon, Jun 18, 2007 at 10:31:30AM -0600, Stephen John Smoogen wrote:
On 6/18/07, Stephen Harris lists@spuddy.org wrote:
I've not heard a good reason to keep SELinux enabled, to be honest. For high sensitivity stuff, sure (much like using SEOS on Solaris for high sensitivity machines - eg those where third parties might have access). But as a general rule for all machines? Why?
Good experience... I have had multiple webservers not have successful
Yup. Webservers are machines where third parties might have access, and so are candidates for enhanced security processes such as SELinux or SEOS.
I've never said there are _no_ cases for SELinux. I was questioning it as a general rule for all machines.
Several of the problems were machines that were not connected to the internet or were deep behind firewalls. The problems were that all it takes is one user who doesnt think well to make all those firewalls/issues useless. E.G the person who coming in from work finds a nice shiney USB fob and plugs it into a work computer to see who it belonged to so they could return it. The guy who downloads an attachment supposedly from the partner in France and wonders why the system runs so slowly. The fellow who has an addiction to porn and decides that he just has to meet that 'blonde' who just wrote him about sharing pictures. Etc etc.
While a lot of these things sound Windows specific.. there is a boutique industry in doing it for Linux especially when you know that the company you are wanting to infiltrate is using Linux for 'security means'.
Or to be direct.. there is no such thing as a secure computer.. it is up to you as the site administrator to determine what is safe enough for Your Site using appropriate risk management. If you believe your site has enough methods of protection or are that the cost of extra security (selinux) is not appropriate for your risk model.. you can turn it off.
On Mon, Jun 18, 2007 at 12:18:40PM -0600, Stephen John Smoogen wrote:
On 6/18/07, Stephen Harris lists@spuddy.org wrote:
I've never said there are _no_ cases for SELinux. I was questioning it as a general rule for all machines.
Several of the problems were machines that were not connected to the internet or were deep behind firewalls. The problems were that all it takes is one user who doesnt think well to make all those firewalls/issues useless. E.G the person who coming in from work finds a nice shiney USB fob and plugs it into a work computer to see who it belonged to so they could return it. The guy who downloads an
[ etc ]
This is why I mentioned "risk profile" in another message. You evaluate the perceived risk, the likely-hood of the event happening, the cost of the event, the "cost" of a potential solution and perform an analysis.
So one might rank the items this: external facing servers: high risk! Automated attacks possible Desktop work stations: moderate. User stupidity highest attack vector General compute server: low risk. Only "trained" staff have access.
Each of those profiles have different uses and require different solutions.
On a DMZ machine you probably wouldn't use unauthenticated naming services (eg LDAP with SSL certs is OK, NIS is bad!). SELinux or SEOS is a very good idea. chroot'd daemons, maybe read-only filesystems, disable unecessary setuid programs, minimal install. Disable hotplug ports.
On a desktop you need GUIs. Centralised naming services. Roaming profiles. Maybe a netboot'd image (no local storage). Disable hotplug ports, or at least minimise scope so that only authorised devices (Blackberry's, whatever) can sync. In particular mass storage isn't allowed. End users don't have root access.
General compute server... well, now we have further ranking; prod/dev/uat boxes have different risk profiles. SOX scoped boxes even more.
And so on.
(Umm, sorry for going on... I work in an area where these things are every day considerations so...)
up to you as the site administrator to determine what is safe enough
Actually, in large companies you have a whole risk organisational structure whose job it is to evaluate these things and determine policy. They straddle the line between technology (my side) and business (my customer) needs and try to balance the two.
for Your Site using appropriate risk management. If you believe your site has enough methods of protection or are that the cost of extra security (selinux) is not appropriate for your risk model.. you can turn it off.
I'd argue the opposite; if you feel you the risk exposure is such that you need the protection then enable it. I've listed cases where this is the case.
That cases exist for SELinux does not mean it should be on by default, and is definitely not deserving of a sheeplike response whenever anyone proposes otherwise.
On 6/18/07, Stephen Harris lists@spuddy.org wrote:
On Mon, Jun 18, 2007 at 12:18:40PM -0600, Stephen John Smoogen wrote:
On 6/18/07, Stephen Harris lists@spuddy.org wrote:
I've never said there are _no_ cases for SELinux. I was questioning it as a general rule for all machines.
Several of the problems were machines that were not connected to the internet or were deep behind firewalls. The problems were that all it takes is one user who doesnt think well to make all those firewalls/issues useless. E.G the person who coming in from work finds a nice shiney USB fob and plugs it into a work computer to see who it belonged to so they could return it. The guy who downloads an
[ etc ]
This is why I mentioned "risk profile" in another message. You evaluate the perceived risk, the likely-hood of the event happening, the cost of the event, the "cost" of a potential solution and perform an analysis.
So one might rank the items this: external facing servers: high risk! Automated attacks possible Desktop work stations: moderate. User stupidity highest attack vector General compute server: low risk. Only "trained" staff have access.
Most of my cleanup/horror stories are on servers that supposedly "trained" staff have access to. I was wondering what a general compute server is... I have seen this term multiple times ot be used for too many items (internal webservers, share servers, financial database, etc) where due to the fact that the desktop could access it in some way.. the stupid user had somehow basically infected it in one way or another.
(Umm, sorry for going on... I work in an area where these things are every day considerations so...)
No problem..
up to you as the site administrator to determine what is safe enough
Actually, in large companies you have a whole risk organisational structure whose job it is to evaluate these things and determine policy. They straddle the line between technology (my side) and business (my customer) needs and try to balance the two.
Hmmmm I guess I havent worked in a big enough business or the ones I have dealt with were more inclined to just keep up with paperwork versus actually making risk analysis. [Is also probably also grumpy today from having to do other peoples work for them.]
for Your Site using appropriate risk management. If you believe your site has enough methods of protection or are that the cost of extra security (selinux) is not appropriate for your risk model.. you can turn it off.
I'd argue the opposite; if you feel you the risk exposure is such that you need the protection then enable it. I've listed cases where this is the case.
That cases exist for SELinux does not mean it should be on by default, and is definitely not deserving of a sheeplike response whenever anyone proposes otherwise.
I am sorry, but while I believe that it was meant in jest... the core of the problem is that turning it off is the default answer from too many people who have no idea why an application isnt working.
Web-application not working, turn off selinux. File-share system not working, turn off selinux. Desktop application you downloaded from rpmfind.net not working, turn off selinux. It usually comes with the recommended advice of use '--force --nodeps' to install/remove RPMS and just keep setting files 777 until your application works. And while your answers are clearly thought out... they are pretty much drowned out in the Slashdot like posts on webforums, email-lists, and IRC where people who have no clue will tell people to turn off Selinux by default and then give the other advice above.
Sorry for the grumpy analogy.. and I probably need a vacation from mailling lists/IRC for a while.. but it seems that this last month has been dealing with people who turned off selinux because someone told them too on IRC etc etc. And those people have no idea why just that they do it because someone told them too.
On Mon, 2007-06-18 at 15:26 -0600, Stephen John Smoogen wrote:
I am sorry, but while I believe that it was meant in jest...
Yes, it was a slight reference to a message from a few days ago.
the core of the problem is that turning it off is the default answer from too many people who have no idea why an application isnt working.
Yes. There are many CentOS-oriented howtos out there that recommend turning off SELinux as their first step, where it is unnecessary for such configuration. It is better to teach people about security in such articles, than to recommend turning off SELinux defacto.
I agree with you (Stephen Harris) that it is not always necessary to have SELinux enabled. But there was a tendency on various lists that started with the non-modular SELinux policy (which is admittedly, much more of a pain to modify) to recommend users to turn of SELinux. I'd like to see things happen the other way around, where people keep it enabled, unless there is a good (informed) reason to so.
It was not my intention to imply that you haven't disabled SELinux for a good reason. I reacted to your message, because it may give some people bad ideas (like turning off SELinux when Xen doesn't work, because they haven't set the correct context for images).
-- Daniel
On 6/18/07, Stephen Harris lists@spuddy.org wrote:
On Mon, Jun 18, 2007 at 12:18:40PM -0600, Stephen John Smoogen wrote:
On 6/18/07, Stephen Harris lists@spuddy.org wrote:
I've never said there are _no_ cases for SELinux. I was questioning it as a general rule for all machines.
Several of the problems were machines that were not connected to the internet or were deep behind firewalls. The problems were that all it takes is one user who doesnt think well to make all those firewalls/issues useless. E.G the person who coming in from work finds a nice shiney USB fob and plugs it into a work computer to see who it belonged to so they could return it. The guy who downloads an
[ etc ]
This is why I mentioned "risk profile" in another message. You evaluate the perceived risk, the likely-hood of the event happening, the cost of the event, the "cost" of a potential solution and perform an analysis.
So one might rank the items this: external facing servers: high risk! Automated attacks possible Desktop work stations: moderate. User stupidity highest attack vector General compute server: low risk. Only "trained" staff have access.
I was really grumpy yesterday.. so I just wanted to say that I believe that in most cases where you are in a low risk.. you might be better off with selinux in permissive mode versus off. Permissive at least will give you a finger print of what might have gone wrong when the PFY plugged in that nice shiney USB fob he found next to his car at lunch.
On Mon, 2007-06-18 at 12:03 -0400, Stephen Harris wrote:
I've not heard a good reason to keep SELinux enabled, to be honest. For high sensitivity stuff, sure (much like using SEOS on Solaris for high sensitivity machines - eg those where third parties might have access). But as a general rule for all machines? Why?
One of the major goals of SELinux is to restrict the impact of 0-day vulnerabilities. If there is an ugly exploit for some network-facing daemon, it is a good idea to restrict the potential damage as possible. Besides that, due to the restrictions that SELinux imposes, it can also catch a class of configuration errors that impact security.
Sure, it does not solve all security problems. But IMO it is a step forward from running daemons with (nearly) the rights of a normal user.
-- Daniel
On Mon, Jun 18, 2007 at 06:45:26PM +0200, Daniel de Kok wrote:
On Mon, 2007-06-18 at 12:03 -0400, Stephen Harris wrote:
I've not heard a good reason to keep SELinux enabled, to be honest. For high sensitivity stuff, sure (much like using SEOS on Solaris for high sensitivity machines - eg those where third parties might have access). But as a general rule for all machines? Why?
One of the major goals of SELinux is to restrict the impact of 0-day vulnerabilities. If there is an ugly exploit for some network-facing daemon, it is a good idea to restrict the potential damage as possible.
"External facing" machines (ie those that can be reached off the internal network) _are_ one of those classes of machines flagged as "high sensitivity". These are candidates for SELinux, SEOS or equivalents. They may be either directly on the internet or in a DMZ area behind firewalls that allow certain incoming traffic (or in large corporations, accessed via VPNs or leased lines from customer sites; a different type of DMZ).
The security rule of thumb here is that such machine _will_ be attacked, and so "security in depth" is the process to apply.
But these are special cases with special "elevated security" rules.
Now... why should such rules apply to machines not thus exposed?
On Mon, 2007-06-18 at 12:56 -0400, Stephen Harris wrote:
The security rule of thumb here is that such machine _will_ be attacked, and so "security in depth" is the process to apply.
There are far more attack vectors than just through network facing daemons. To name just one example, web browsers. Unfortunately, Firefox is not yet protected by the targeted policy. Hopefully that will happen one day.
-- Daniel
On Mon, Jun 18, 2007 at 07:17:54PM +0200, Daniel de Kok wrote:
On Mon, 2007-06-18 at 12:56 -0400, Stephen Harris wrote:
The security rule of thumb here is that such machine _will_ be attacked, and so "security in depth" is the process to apply.
There are far more attack vectors than just through network facing daemons. To name just one example, web browsers. Unfortunately, Firefox is not yet protected by the targeted policy. Hopefully that will happen one day.
Web browsers typically don't run as root and don't run on servers, but work stations. They also require users to access "infected" sites.
Daemons on internet facing systems generally provide access to application data (eg a web application) or system resources (eg ssh) with higher priveleges and are candidates for automated zombie attacks and, therefore, have a much bigger risk profile.
-
Daniel de Kok -
Jordi Espasa Clofent -
Rick Barnes -
Stephen Harris -
Stephen John Smoogen