Hello mailing list! I have been working with XCP a little bit, and I have the impression that this distro is insecure. First, it does not look like update repositories are enabled inside /etc/yum.repos.d, although I''m from an apt background so I may be misinterpreting that. Where will my security updates come from? Next, it appears that the root password hash is directly stored inside /etc/passwd, which is set to world-readable! There does not appear to be an /etc/shadow file at all. Unfortunately I am dropping the distro entirely due to security concerns, I hope that these problems can be fixed. AJ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 09/05/2011 21:41, Adrien Guillon wrote:> Hello mailing list! > > I have been working with XCP a little bit, and I have the impression > that this distro is insecure. First, it does not look like update > repositories are enabled inside /etc/yum.repos.d, although I''m from an > apt background so I may be misinterpreting that. Where will my > security updates come from? > > Next, it appears that the root password hash is directly stored inside > /etc/passwd, which is set to world-readable! There does not appear to > be an /etc/shadow file at all. > > Unfortunately I am dropping the distro entirely due to security > concerns, I hope that these problems can be fixed. > > AJ > > >Hi AJ, Since this is open software we are talking about, you are free to modify these settings. However, in my opinion, XCP is designed to be only accessed via the management software (The one used for the commercial Xen Server should work), so all your security generally comes from the fact that the VMs (DomUs) have no access to the XCP host OS (Dom0). I think the assumption is, that if you don''t log in to XCP and execute binaries, then exploits won''t occur. Of course, I don''t use XCP, and know little about it - I''m just using whatever common sense I have on the matter (in that if you don''t have multiple users on the system, then world readable permissions don''t matter). But I''d be interested to hear what someone else more qualified on the matter has to say Cheers _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Well, you are right from the multi-user point of view regarding the passwd file, but XCP is designed as appliance, xe utility or something speaking xapi is a way of interfacing it, no user other than root should access dom0. Updates - question of stability, i hope you do not want to risk reload of all your VM`s due to libc changes or something like that :). You need to update what? Xen hypervisor? Openvswitch, xapi toolstack? Everything should be locked down on lower levels (network access to dom0, physical access to appliances). Try to change the point of view and stop looking at it as a standard multiuser linux enviroment. r. On 05/09/2011 10:41 PM, Adrien Guillon wrote:> Hello mailing list! > > I have been working with XCP a little bit, and I have the impression > that this distro is insecure. First, it does not look like update > repositories are enabled inside /etc/yum.repos.d, although I''m from an > apt background so I may be misinterpreting that. Where will my > security updates come from? > > Next, it appears that the root password hash is directly stored inside > /etc/passwd, which is set to world-readable! There does not appear to > be an /etc/shadow file at all. > > Unfortunately I am dropping the distro entirely due to security > concerns, I hope that these problems can be fixed. > > AJ > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Security updates are common, and generally do not make major interface changes by design. I have no desire to update anything aside from receiving fixes for buffer overflows, or other exploits that are found in the wild. The system in question should be in production for several years, and security patches are inevitable during that period of time. It likely took some effort to eliminate /etc/shadow in the first place, as this has been standard practice for a very long time. I will not debate the merits of storing hashes in /etc/passwd or /etc/shadow because that debate ended a very long time ago. Quite simply this distro has a major security flaw. On Mon, May 9, 2011 at 5:16 PM, riki <phobie@axfr.org> wrote:> Well, you are right from the multi-user point of view regarding the passwd > file, but XCP is designed as appliance, xe utility or something speaking > xapi is a way of interfacing it, no user other than root should access dom0. > > Updates - question of stability, i hope you do not want to risk reload of > all your VM`s due to libc changes or something like that :). You need to > update what? Xen hypervisor? Openvswitch, xapi toolstack? Everything should > be locked down on lower levels (network access to dom0, physical access to > appliances). > > Try to change the point of view and stop looking at it as a standard > multiuser linux enviroment. > > r. > > On 05/09/2011 10:41 PM, Adrien Guillon wrote: >> >> Hello mailing list! >> >> I have been working with XCP a little bit, and I have the impression >> that this distro is insecure. First, it does not look like update >> repositories are enabled inside /etc/yum.repos.d, although I''m from an >> apt background so I may be misinterpreting that. Where will my >> security updates come from? >> >> Next, it appears that the root password hash is directly stored inside >> /etc/passwd, which is set to world-readable! There does not appear to >> be an /etc/shadow file at all. >> >> Unfortunately I am dropping the distro entirely due to security >> concerns, I hope that these problems can be fixed. >> >> AJ >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Do you know how many "commercial" Linux based appliances there are out there? How many of them follow the patch cycle of the Linux flavor they are based on? Have you offered the community any suggestions on how to improve the security model of XCP? We are all ears. As for updates not having the potential to break things, I strongly disagree. Kind Regards, Christopher James Petrolino On May 9, 2011, at 5:30 PM, Adrien Guillon <aj.guillon@gmail.com> wrote:> Security updates are common, and generally do not make major interface > changes by design. I have no desire to update anything aside from > receiving fixes for buffer overflows, or other exploits that are found > in the wild. The system in question should be in production for > several years, and security patches are inevitable during that period > of time. > > It likely took some effort to eliminate /etc/shadow in the first > place, as this has been standard practice for a very long time. I > will not debate the merits of storing hashes in /etc/passwd or > /etc/shadow because that debate ended a very long time ago. Quite > simply this distro has a major security flaw. > > > On Mon, May 9, 2011 at 5:16 PM, riki <phobie@axfr.org> wrote: >> Well, you are right from the multi-user point of view regarding the passwd >> file, but XCP is designed as appliance, xe utility or something speaking >> xapi is a way of interfacing it, no user other than root should access dom0. >> >> Updates - question of stability, i hope you do not want to risk reload of >> all your VM`s due to libc changes or something like that :). You need to >> update what? Xen hypervisor? Openvswitch, xapi toolstack? Everything should >> be locked down on lower levels (network access to dom0, physical access to >> appliances). >> >> Try to change the point of view and stop looking at it as a standard >> multiuser linux enviroment. >> >> r. >> >> On 05/09/2011 10:41 PM, Adrien Guillon wrote: >>> >>> Hello mailing list! >>> >>> I have been working with XCP a little bit, and I have the impression >>> that this distro is insecure. First, it does not look like update >>> repositories are enabled inside /etc/yum.repos.d, although I''m from an >>> apt background so I may be misinterpreting that. Where will my >>> security updates come from? >>> >>> Next, it appears that the root password hash is directly stored inside >>> /etc/passwd, which is set to world-readable! There does not appear to >>> be an /etc/shadow file at all. >>> >>> Unfortunately I am dropping the distro entirely due to security >>> concerns, I hope that these problems can be fixed. >>> >>> AJ >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xensource.com >>> http://lists.xensource.com/xen-users >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users >> > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Why is flaming always the first line with you people? He brought up 2 very important issues in the form of questions which should be addressed: 1. Security flaw in XCP? 2. Where are the patches/updates going to come from and how? If you want to flame someone go ahead and flame me, but Adrien''s questions seem sincere and important! Regards, Randy Katz On 5/9/2011 2:51 PM, Chris Petrolino wrote:> Do you know how many "commercial" Linux based appliances there are out > there? How many of them follow the patch cycle of the Linux flavor > they are based on? > > Have you offered the community any suggestions on how to improve the > security model of XCP? We are all ears. > > As for updates not having the potential to break things, I strongly disagree. > > Kind Regards, > > Christopher James Petrolino > > > On May 9, 2011, at 5:30 PM, Adrien Guillon<aj.guillon@gmail.com> wrote: > >> Security updates are common, and generally do not make major interface >> changes by design. I have no desire to update anything aside from >> receiving fixes for buffer overflows, or other exploits that are found >> in the wild. The system in question should be in production for >> several years, and security patches are inevitable during that period >> of time. >> >> It likely took some effort to eliminate /etc/shadow in the first >> place, as this has been standard practice for a very long time. I >> will not debate the merits of storing hashes in /etc/passwd or >> /etc/shadow because that debate ended a very long time ago. Quite >> simply this distro has a major security flaw. >> >> >> On Mon, May 9, 2011 at 5:16 PM, riki<phobie@axfr.org> wrote: >>> Well, you are right from the multi-user point of view regarding the passwd >>> file, but XCP is designed as appliance, xe utility or something speaking >>> xapi is a way of interfacing it, no user other than root should access dom0. >>> >>> Updates - question of stability, i hope you do not want to risk reload of >>> all your VM`s due to libc changes or something like that :). You need to >>> update what? Xen hypervisor? Openvswitch, xapi toolstack? Everything should >>> be locked down on lower levels (network access to dom0, physical access to >>> appliances). >>> >>> Try to change the point of view and stop looking at it as a standard >>> multiuser linux enviroment. >>> >>> r. >>> >>> On 05/09/2011 10:41 PM, Adrien Guillon wrote: >>>> Hello mailing list! >>>> >>>> I have been working with XCP a little bit, and I have the impression >>>> that this distro is insecure. First, it does not look like update >>>> repositories are enabled inside /etc/yum.repos.d, although I''m from an >>>> apt background so I may be misinterpreting that. Where will my >>>> security updates come from? >>>> >>>> Next, it appears that the root password hash is directly stored inside >>>> /etc/passwd, which is set to world-readable! There does not appear to >>>> be an /etc/shadow file at all. >>>> >>>> Unfortunately I am dropping the distro entirely due to security >>>> concerns, I hope that these problems can be fixed. >>>> >>>> AJ >>>> >>>> _______________________________________________ >>>> Xen-users mailing list >>>> Xen-users@lists.xensource.com >>>> http://lists.xensource.com/xen-users >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xensource.com >>> http://lists.xensource.com/xen-users >>> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I don''t think anyone is intentionally trying to be a flamer here but I also don''t think it is the most productive to send a message to the list that says "XCP is missing X and Y so I''m not going to use it. I too have found several things that are important to me lacking from XCP, but I also see the amazing potential and appreciate all the hard work that has been put into it so far. Anyway back to what the OP brought up - 1. /etc/shadow is still not present in XenServer 5.6 fp1 as far as I can tell. See here - http://forums.citrix.com/message.jspa?messageID=1552977 2. It certainly would be nice to see dedicated XCP repositories created, but my hunch is that there are probably a lot of reasons why it hasn''t happened yet. On Mon, May 9, 2011 at 8:26 PM, Randy Katz <rkatz@simplicityhosting.com> wrote:> Why is flaming always the first line with you people? He brought up 2 very > important issues in the > form of questions which should be addressed: > > 1. Security flaw in XCP? > 2. Where are the patches/updates going to come from and how? > > If you want to flame someone go ahead and flame me, but Adrien''s questions > seem sincere and important! > > Regards, > Randy Katz > > On 5/9/2011 2:51 PM, Chris Petrolino wrote: >> >> Do you know how many "commercial" Linux based appliances there are out >> there? How many of them follow the patch cycle of the Linux flavor >> they are based on? >> >> Have you offered the community any suggestions on how to improve the >> security model of XCP? We are all ears. >> >> As for updates not having the potential to break things, I strongly >> disagree. >> >> Kind Regards, >> >> Christopher James Petrolino >> >> >> On May 9, 2011, at 5:30 PM, Adrien Guillon<aj.guillon@gmail.com> wrote: >> >>> Security updates are common, and generally do not make major interface >>> changes by design. I have no desire to update anything aside from >>> receiving fixes for buffer overflows, or other exploits that are found >>> in the wild. The system in question should be in production for >>> several years, and security patches are inevitable during that period >>> of time. >>> >>> It likely took some effort to eliminate /etc/shadow in the first >>> place, as this has been standard practice for a very long time. I >>> will not debate the merits of storing hashes in /etc/passwd or >>> /etc/shadow because that debate ended a very long time ago. Quite >>> simply this distro has a major security flaw. >>> >>> >>> On Mon, May 9, 2011 at 5:16 PM, riki<phobie@axfr.org> wrote: >>>> >>>> Well, you are right from the multi-user point of view regarding the >>>> passwd >>>> file, but XCP is designed as appliance, xe utility or something speaking >>>> xapi is a way of interfacing it, no user other than root should access >>>> dom0. >>>> >>>> Updates - question of stability, i hope you do not want to risk reload >>>> of >>>> all your VM`s due to libc changes or something like that :). You need >>>> to >>>> update what? Xen hypervisor? Openvswitch, xapi toolstack? Everything >>>> should >>>> be locked down on lower levels (network access to dom0, physical access >>>> to >>>> appliances). >>>> >>>> Try to change the point of view and stop looking at it as a standard >>>> multiuser linux enviroment. >>>> >>>> r. >>>> >>>> On 05/09/2011 10:41 PM, Adrien Guillon wrote: >>>>> >>>>> Hello mailing list! >>>>> >>>>> I have been working with XCP a little bit, and I have the impression >>>>> that this distro is insecure. First, it does not look like update >>>>> repositories are enabled inside /etc/yum.repos.d, although I''m from an >>>>> apt background so I may be misinterpreting that. Where will my >>>>> security updates come from? >>>>> >>>>> Next, it appears that the root password hash is directly stored inside >>>>> /etc/passwd, which is set to world-readable! There does not appear to >>>>> be an /etc/shadow file at all. >>>>> >>>>> Unfortunately I am dropping the distro entirely due to security >>>>> concerns, I hope that these problems can be fixed. >>>>> >>>>> AJ >>>>> >>>>> _______________________________________________ >>>>> Xen-users mailing list >>>>> Xen-users@lists.xensource.com >>>>> http://lists.xensource.com/xen-users >>>> >>>> _______________________________________________ >>>> Xen-users mailing list >>>> Xen-users@lists.xensource.com >>>> http://lists.xensource.com/xen-users >>>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xensource.com >>> http://lists.xensource.com/xen-users >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users >> > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On May 9, 2011, at 6:29 PM, Adrien Guillon wrote:> Security updates are common, and generally do not make major interface > changes by design. I have no desire to update anything aside from > receiving fixes for buffer overflows, or other exploits that are found > in the wild. The system in question should be in production for > several years, and security patches are inevitable during that period > of time.In Xen''s case I will have to disagree. If you''re trying to build an HA cluster, you need to make sure all your nodes have precisely the same dom0 if you want things like live migration to work properly. Besides disrupting one single system, problems caused by updates could potentially harm the entire pool (how do you update all dom0 nodes to the same software version at the same time and make sure nothing will try to be "live migrated" from one node to another in the meanwhile?) The concern about buffer overflows is intrinsically related to security, which is the next topic...> It likely took some effort to eliminate /etc/shadow in the first > place, as this has been standard practice for a very long time. I > will not debate the merits of storing hashes in /etc/passwd or > /etc/shadow because that debate ended a very long time ago. Quite > simply this distro has a major security flaw.As others have pointed out, dom0 is not supposed to be accessed by anybody other than root. I would go further and say it''s not supposed to be accessed over any public network, such as the Internet or the wifi network you''d find in a Starbucks. I believe the main idea is that you should isolate dom0 from the world in all possible ways, so no matter what security flaws it might have, they will never be exploited. Maybe they should make it explicit like: you should always run dom0 on a private network, controlled and secured by VPNs or any other methods. Best regads, Eduardo Bragatto _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, The points highlighted don''t represent security risks if the dom0 is properly isolated on a secure management network. Following that, the only attack vector then available is exploitation of the hypervisor from untrusted guests. At which point UNIX permissions aren''t worth much. However, the fact someone was to bring up the points signifies there is a lack of communication as to how XCP and systems like it are meant to be employed. Possibly some further documentation on XCP best practices is in order? Joseph. On 10 May 2011 11:44, Eduardo Bragatto <eduardo@bragatto.com> wrote:> On May 9, 2011, at 6:29 PM, Adrien Guillon wrote: > >> Security updates are common, and generally do not make major interface >> changes by design. I have no desire to update anything aside from >> receiving fixes for buffer overflows, or other exploits that are found >> in the wild. The system in question should be in production for >> several years, and security patches are inevitable during that period >> of time. > > In Xen''s case I will have to disagree. If you''re trying to build an HA > cluster, you need to make sure all your nodes have precisely the same dom0 > if you want things like live migration to work properly. > > Besides disrupting one single system, problems caused by updates could > potentially harm the entire pool (how do you update all dom0 nodes to the > same software version at the same time and make sure nothing will try to be > "live migrated" from one node to another in the meanwhile?) > > The concern about buffer overflows is intrinsically related to security, > which is the next topic... > >> It likely took some effort to eliminate /etc/shadow in the first >> place, as this has been standard practice for a very long time. I >> will not debate the merits of storing hashes in /etc/passwd or >> /etc/shadow because that debate ended a very long time ago. Quite >> simply this distro has a major security flaw. > > As others have pointed out, dom0 is not supposed to be accessed by anybody > other than root. I would go further and say it''s not supposed to be accessed > over any public network, such as the Internet or the wifi network you''d find > in a Starbucks. > > I believe the main idea is that you should isolate dom0 from the world in > all possible ways, so no matter what security flaws it might have, they will > never be exploited. > > Maybe they should make it explicit like: you should always run dom0 on a > private network, controlled and secured by VPNs or any other methods. > > Best regads, > Eduardo Bragatto > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >-- Kind regards, Joseph. Founder | Director Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Joseph you are exactly right documentation is definitely in need of work in the case of XCP. Fortunately for the community the person who is spearheading the effort is a really bright individual and in the long run the documentation will get there. On Mon, May 9, 2011 at 10:24 PM, Joseph Glanville <joseph.glanville@orionvm.com.au> wrote:> Hi, > > The points highlighted don''t represent security risks if the dom0 is > properly isolated on a secure management network. > Following that, the only attack vector then available is exploitation > of the hypervisor from untrusted guests. At which point UNIX > permissions aren''t worth much. > > However, the fact someone was to bring up the points signifies there > is a lack of communication as to how XCP and systems like it are meant > to be employed. Possibly some further documentation on XCP best > practices is in order? > > Joseph. > > On 10 May 2011 11:44, Eduardo Bragatto <eduardo@bragatto.com> wrote: >> On May 9, 2011, at 6:29 PM, Adrien Guillon wrote: >> >>> Security updates are common, and generally do not make major interface >>> changes by design. I have no desire to update anything aside from >>> receiving fixes for buffer overflows, or other exploits that are found >>> in the wild. The system in question should be in production for >>> several years, and security patches are inevitable during that period >>> of time. >> >> In Xen''s case I will have to disagree. If you''re trying to build an HA >> cluster, you need to make sure all your nodes have precisely the same dom0 >> if you want things like live migration to work properly. >> >> Besides disrupting one single system, problems caused by updates could >> potentially harm the entire pool (how do you update all dom0 nodes to the >> same software version at the same time and make sure nothing will try to be >> "live migrated" from one node to another in the meanwhile?) >> >> The concern about buffer overflows is intrinsically related to security, >> which is the next topic... >> >>> It likely took some effort to eliminate /etc/shadow in the first >>> place, as this has been standard practice for a very long time. I >>> will not debate the merits of storing hashes in /etc/passwd or >>> /etc/shadow because that debate ended a very long time ago. Quite >>> simply this distro has a major security flaw. >> >> As others have pointed out, dom0 is not supposed to be accessed by anybody >> other than root. I would go further and say it''s not supposed to be accessed >> over any public network, such as the Internet or the wifi network you''d find >> in a Starbucks. >> >> I believe the main idea is that you should isolate dom0 from the world in >> all possible ways, so no matter what security flaws it might have, they will >> never be exploited. >> >> Maybe they should make it explicit like: you should always run dom0 on a >> private network, controlled and secured by VPNs or any other methods. >> >> Best regads, >> Eduardo Bragatto >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users >> > > > > -- > Kind regards, > Joseph. > Founder | Director > Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56 > 99 52 | Mobile: 0428 754 846 > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, May 10, 2011 at 4:29 AM, Adrien Guillon <aj.guillon@gmail.com> wrote:> Security updates are common, and generally do not make major interface > changes by design. I have no desire to update anything aside from > receiving fixes for buffer overflows, or other exploits that are found > in the wild. The system in question should be in production for > several years, and security patches are inevitable during that period > of time.If you''re familiar with Centos (which is what XCP is based on), you''ll notice that each point release (e.g. 5.5 -> 5.6) is usually a combo of bug fix and new features. While the new features/version had some level of testing (mainly by RedHat), there are always the possibilty that it will introduce some level of incompatibilty with older installed version (this happens for example when RedHat rebased their Xen package from 3.0 to 3.1.2) So if you "have no desire to update anything aside from receiving fixes for buffer overflows, or other exploits that are found in the wild", it''s actually harder to implement than it sounds. I''m not saying you''re wrong. I''m simply saying implementing it is not an easy task.> > It likely took some effort to eliminate /etc/shadow in the first > place, as this has been standard practice for a very long time. I > will not debate the merits of storing hashes in /etc/passwd or > /etc/shadow because that debate ended a very long time ago.Christopher''s mail has a link explaining why password is currently stored in /etc/passwd> Quite > simply this distro has a major security flaw.I wouldn''t call XCP a "distro". It''s more like an appliance. IIRC the supported "update" process is NOT by using yum (or some common distro mechanism), but by a rolling upgrade using the next XCP version. That being said, xen-users is mostly where users hang around. If you have interest in contributing to improve XCP, you''d probably be better posting to xen-devel. -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> The points highlighted don''t represent security risks if the dom0 is > properly isolated on a secure management network.Unfortunately there are some situations where even having an air-gap between networks, is not considered secure enough. Having the password hashes in world-readable files is basically a no-no, and would mean that this product could not go into production use. Basically this appears to be a relaxation in security against the ''norm'', if this is only required due to keeping different pool members in sync, I think that investigation should be made into an alternative method of synchronising the members. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, Sorry I wasn''t completely clear. The reason why the use of /etc/passwd vs /etc/shadow is non-consequential is that XCP is a single user machine where all access is via UID 0. As such UNIX file permissions are effectively useless. For all intents and purposes 700 = 777 if you are always root and everything is owned by root yes? XCP could be secured further through the use of a mulit-user environment, sudo, selinux and grsec patches but for it''s usecase it would be entirely overkill. In the usecases that XCP will be employed a single user environment is all that is required for the reason that the only trusted system in the stack is the management controller. XCP is not designed to have users ever using shell access on their XCP nodes. All operations on XCP are carried out though deamons running as root all of which can read /etc/passwd or /etc/shadow regardless - as such it would not add any extra security. As I noted earlier it is possible to make XCP secure enough to live on a public network, but I don''t think it would be a beneficial use of XCP developers time. Does this further clarify why changing to /etc/shadow would be of no consequence? Joseph. On 10 May 2011 17:16, A Cold Penguin <verycoldpenguin@hotmail.com> wrote:>> The points highlighted don''t represent security risks if the dom0 is >> properly isolated on a secure management network. > > Unfortunately there are some situations where even having an air-gap between > networks, is not considered secure enough. > Having the password hashes in world-readable files is basically a no-no, and > would mean that this product could not go into production use. > Basically this appears to be a relaxation in security against the ''norm'', if > this is only required due to keeping different pool members in sync, > I think that investigation should be made into an alternative method of > synchronising the members. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >-- Kind regards, Joseph. Founder | Director Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>Sorry I wasn''t completely clear. >The reason why the use of /etc/passwd vs /etc/shadow is >non-consequential is that XCP is a single user machine where all >access is via UID 0. >As such UNIX file permissions are effectively useless. For all intents >and purposes 700 = 777 if you are always root and everything is owned >by root yes?....>Does this further clarify why changing to /etc/shadow would be of no >consequence?No, if anything, it makes even less sense. If all the daemons are running as root, then the excuse that was put forward, that using shadow would stop the necessary daemons from being able to perform their synchronisation properly, is moot. In the situation I am talking about here, root is often not used as a super-user. Although it would be understood that in the requirement of XCP this might be bypassed, the easy-access by keeping the password in a world-readable file would not be acceptable. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 05/10/2011 10:46 PM, A Cold Penguin wrote:> >>Sorry I wasn''t completely clear. >>The reason why the use of /etc/passwd vs /etc/shadow is >>non-consequential is that XCP is a single user machine where all >>access is via UID 0. >>As such UNIX file permissions are effectively useless. For all intents >>and purposes 700 = 777 if you are always root and everything is owned >>by root yes? > .... >>Does this further clarify why changing to /etc/shadow would be of no >>consequence? > > > No, if anything, it makes even less sense. If all the daemons are running as root, then the excuse that was put forward, that using shadow would stop the necessary daemons from being able to perform their synchronisation properly, is moot. > In the situation I am talking about here, root is often not used as a super-user. Although it would be understood that in the requirement of XCP this might be bypassed, the easy-access by keeping the password in a world-readable file would not be acceptable.Is it possible to stop looking at the XCP as the unix-like distribution based on centos linux and start to look at it as a appliance. Are you guys evaluationg your microwave oven, fridge, NAS, set-top box and your smart TV? r. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Riki, if you hack my TV I will call XCP my "appliance"! On 5/10/2011 3:05 PM, riki wrote:> > > On 05/10/2011 10:46 PM, A Cold Penguin wrote: >> >>> Sorry I wasn''t completely clear. >>> The reason why the use of /etc/passwd vs /etc/shadow is >>> non-consequential is that XCP is a single user machine where all >>> access is via UID 0. >>> As such UNIX file permissions are effectively useless. For all intents >>> and purposes 700 = 777 if you are always root and everything is owned >>> by root yes? >> .... >>> Does this further clarify why changing to /etc/shadow would be of no >>> consequence? >> >> >> No, if anything, it makes even less sense. If all the daemons are >> running as root, then the excuse that was put forward, that using >> shadow would stop the necessary daemons from being able to perform >> their synchronisation properly, is moot. >> In the situation I am talking about here, root is often not used as a >> super-user. Although it would be understood that in the requirement >> of XCP this might be bypassed, the easy-access by keeping the >> password in a world-readable file would not be acceptable. > > Is it possible to stop looking at the XCP as the unix-like > distribution based on centos linux and start to look at it as a > appliance. Are you guys evaluationg your microwave oven, fridge, NAS, > set-top box and your smart TV? > > r. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
The dom0 portion of a XCP appliance is not designed to operate as a standard multi user Unix SSH host. The only way you can access the dom0 at all is if you already have the root password. There are no other users in the dom0, so there is no reason to worry about file permissions within the dom0 in the same manor that you typically would in a multi user host. The only way you can steal the passwd file is if you already know the root password. That is already secure enough. -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of A Cold Penguin Sent: Tuesday, May 10, 2011 3:46 PM To: xen-users@lists.xensource.com Subject: [Xen-users] Re: XCP: Insecure Distro ?>Sorry I wasn''t completely clear.>The reason why the use of /etc/passwd vs /etc/shadow is>non-consequential is that XCP is a single user machine where all>access is via UID 0.>As such UNIX file permissions are effectively useless. For all intents>and purposes 700 = 777 if you are always root and everything is owned>by root yes?....>Does this further clarify why changing to /etc/shadow would be of no>consequence?No, if anything, it makes even less sense. If all the daemons are running as root, then the excuse that was put forward, that using shadow would stop the necessary daemons from being able to perform their synchronisation properly, is moot. In the situation I am talking about here, root is often not used as a super-user. Although it would be understood that in the requirement of XCP this might be bypassed, the easy-access by keeping the password in a world-readable file would not be acceptable. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
You are referring to a "no-no" that refers to multi user situations. XCP''s dom0 is a single user (root) environment, so you don''t have to worry about hardening the security in the same ways that you would in a multi user Unix SSH environment. In the case of XCP''s dom0, the passwd file is only "vulnerable" if you are already logged into the dom0 as root. And if you are already logged in as root, you would not need to worry about the passwd file. -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of A Cold Penguin Sent: Tuesday, May 10, 2011 2:16 AM To: xen-users@lists.xensource.com Subject: Re: [Xen-users] XCP: Insecure Distro ?> The points highlighted don''t represent security risks if the dom0 is> properly isolated on a secure management network.Unfortunately there are some situations where even having an air-gap between networks, is not considered secure enough. Having the password hashes in world-readable files is basically a no-no, and would mean that this product could not go into production use. Basically this appears to be a relaxation in security against the ''norm'', if this is only required due to keeping different pool members in sync, I think that investigation should be made into an alternative method of synchronising the members. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
For those of you who might be interested, Karl Fogel has a great book called "Producing Open Source Software", and a potentially relevant section can be found here: http://producingoss.com/en/common-pitfalls.html I brought up two issues regarding XCP. First, is that /etc/passwd has the actual password hash stored within. I have read arguments in this thread to the effect that "it doesn''t matter because dom0 is single user". I''m not sure what, precisely is meant by "single user" in this context. "Single user" to me normally refers to an init level where the system has networking disabled, and the system is undergoing maintenance with an admin standing in a room typing away at a local terminal. I doubt this is what is meant, instead I believe you mean that "only one user should have access". In this matter, and those familiar with Linux user philosophy can skip this, the root account does more than offer a user access to the system. The root account is the owner of executables, the custodian of the kernel, and master of the machine. This root account is quite special, and you will notice that very few programs are allowed to run as root. Many programs will start as root, and will drop down to a non-root system user with fewer privileges as quickly as possible. This is done so that in the event one of these programs is compromised it can do limited damage. In the context of XCP, any compromised (or misconfigured) application can now read the password hashes from /etc/passwd. This discussion has refuted that even this is not a big deal, because dom0 has limited privileges. Now, I am not intimately familiar with Xen, but are you telling me that there is zero potential for dom0 to interact with any other running VM? It cannot, say, read partitions allocated with LVM for virtual machines? Cannot copy file that act as storage for the VMs? Of course, the kernel cannot be patched in /boot either and the system rebooted? None of these possibilities exist because of some unique properties of dom0? I''m no Xen expert, so can someone can fill in these blanks? Another argument that has come up was that the network card on dom0 is on a trusted network, now this is news to me. None of my research showed this, and certainly for an assumption so critically important it should be in enormous block letters when you configure XCP in case you missed it like I did. In my usage scenario, this machine is going onto the real Internet, no firewalls, no nothing. I was completely unaware that such assumptions of a friendly world were in place. Participants of this thread have also thrown around the idea that XCP is an "appliance" not a distribution. Can someone give me a legitimate technical definition of an appliance? My search for "distribution vs. appliance" on Google brings up a washing machine place. My second point regarded updates. It was suggested that the way to deal with this is to reinstall. In a production environment this is often not acceptable. I believe it would be worth the effort to find a way to send out security updates without affecting Xen itself. I hope that this discussion can be helpful. Sincerely, AJ On Tue, May 10, 2011 at 7:11 PM, <admin@xenhive.com> wrote:> You are referring to a “no-no” that refers to multi user situations. XCP’s > dom0 is a single user (root) environment, so you don’t have to worry about > hardening the security in the same ways that you would in a multi user Unix > SSH environment. In the case of XCP’s dom0, the passwd file is only > “vulnerable” if you are already logged into the dom0 as root. And if you > are already logged in as root, you would not need to worry about the passwd > file. > > > > -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of A Cold Penguin > Sent: Tuesday, May 10, 2011 2:16 AM > To: xen-users@lists.xensource.com > Subject: Re: [Xen-users] XCP: Insecure Distro ? > > > >> The points highlighted don''t represent security risks if the dom0 is > >> properly isolated on a secure management network. > > > > Unfortunately there are some situations where even having an air-gap between > networks, is not considered secure enough. > > Having the password hashes in world-readable files is basically a no-no, and > would mean that this product could not go into production use. > > Basically this appears to be a relaxation in security against the ''norm'', if > this is only required due to keeping different pool members in sync, > > I think that investigation should be made into an alternative method of > synchronising the members. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, May 11, 2011 at 7:47 AM, Adrien Guillon <aj.guillon@gmail.com> wrote:> Now, I am not intimately familiar with Xen, but are you telling me > that there is zero potential for dom0 to interact with any other > running VM? It cannot, say, read partitions allocated with LVM for > virtual machines? Cannot copy file that act as storage for the VMs? > Of course, the kernel cannot be patched in /boot either and the system > rebooted? None of these possibilities exist because of some unique > properties of dom0? I''m no Xen expert, so can someone can fill in > these blanks?dom0 can access domU''s storage. The point that was given by others is NOT that dom0 can''t acess domU''s storage. Rather, access to XCP dom0 is already LIMITED in that: - it should be on a private, management network - it does not run any unnecessary services - most admin access should be done via the web interface. with that setup, unpriviledged user common in normal Linux distros (e.g. httpd user, or some other non-root user) will likely NOT be able to access arbitrary part of dom0''s filesystem anyway, so arguably filesystem permission is not as critical as it is on normal Linux distro.> > Another argument that has come up was that the network card on dom0 is > on a trusted network, now this is news to me. None of my research > showed this, and certainly for an assumption so critically important > it should be in enormous block letters when you configure XCP in case > you missed it like I did. In my usage scenario, this machine is going > onto the real Internet, no firewalls, no nothing. I was completely > unaware that such assumptions of a friendly world were in place.Are you saying that (for example) when you have a Cisco switch/router you''ll put the management interface in public network? Seriously? The best practice for management interface (whether it''s XCP, router, or server ILO) is to put it in private network, separate from normal traffic. In practice, this can be just a separate vlan.> > Participants of this thread have also thrown around the idea that XCP > is an "appliance" not a distribution. Can someone give me a > legitimate technical definition of an appliance? My search for > "distribution vs. appliance" on Google brings up a washing machine > place.The most relevant part from wikipedia http://en.wikipedia.org/wiki/Computer_appliance " These devices became known as "appliances" because of their similarity to home appliances, which are generally "closed and sealed" – not serviceable by the owner. In computer appliances the hardware is also usually sealed and not repairable or upgradeable by the user. " in XCP case, the "not repairable or upgradeable" part would refer to the fact that you should not perform any manual/additional customization that you usually use on normal distro, like: - install additional package - use any standard distro package management command (like yum) - add system user using "useradd" or similar While some appliance (example: Linux-based Brocade SAN switches, or Allot bandwitdh management appliance) might allow root access via ssh directly, using it to modify the system directly is not supported and can void your warranty/support.> > My second point regarded updates. It was suggested that the way to > deal with this is to reinstall. In a production environment this is > often not acceptable. I believe it would be worth the effort to find > a way to send out security updates without affecting Xen itself.That would be useful, true. But like I said earlier implementing it is not as easy at it sounds. So to sum it up: - Some of your concerns are valid, although I disagree on the degree of importance - XCP has taken least-effort path to make the system secure-enough - you can contribute to XCP development since it''s open source. AFAIK the best way to do so by joining xen-devel or xen-api list and sumbit your improvements there - If you only want a feature/bug fix added without implementing it yourself, then AFAIK the best way to do that is to get a Citrix XenServer support and file a feature request. Again, xen-users is mostly where Xen users (not developers) hang around, so even if there''s a big flame war here, there''s no guarantee that it would catch a developer''s attention :) -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Now, I am not intimately familiar with Xen, but are you telling me > that there is zero potential for dom0 to interact with any other > running VM? It cannot, say, read partitions allocated with LVM for > virtual machines? Cannot copy file that act as storage for the VMs? > Of course, the kernel cannot be patched in /boot either and the system > rebooted? None of these possibilities exist because of some unique > properties of dom0? I''m no Xen expert, so can someone can fill in > these blanks? >Sure it can. It is the "trusted Domain" after all. However, the reverse isn''t true. A DomU cannot access anything running on the Dom0 without going via a network. I think the bottom line is that if you want to use your Dom0 in the traditional sense (as in, use it like a "real" linux environment), then maybe XCP isn''t for you. You shouldn''t really need to log into the shell of XCP at all. If you are finding that you do, then maybe you should just install Xen with a CentOS Dom0 and work from there. If you don''t log into the shell, then you won''t be executing any binaries yourself, hense nothing can be exploited. It goes back to the Washing Machine concept. If you don''t plug your laptop up to the RS232 terminal of your TV/Washing Machine/Microwave/Kitchen Sink, then it can''t be hacked.> Another argument that has come up was that the network card on dom0 is > on a trusted network, now this is news to me. None of my research > showed this, and certainly for an assumption so critically important > it should be in enormous block letters when you configure XCP in case > you missed it like I did.You should nevel place a server management interface on a VLAN that is accessable from the internet. If you do, at least firewall the box!> In my usage scenario, this machine is going > onto the real Internet, no firewalls, no nothing.This comment is alarming. Usually, the phrases "real Internet" and "no firewalls" don''t go together is a huge cause for concern. I don''t think having no /etc/shadow is your biggest problem.... If you are scanning for a PCI DSS compliant environment, I suggest you switch off your network, go back to the drawing board, and re-evaluate your network topology.> I was completely > unaware that such assumptions of a friendly world were in place. >For a management interface, a friendly world is always assumed. Just having a password isn''t enough security. You shouldn''t give outside users access to a login prompt that they are able to log in as root with (that''s what VPNs are for). Also, if you''re doing a PCI DSS audit, any VPN used must be 2-factor, but this is OT.> Participants of this thread have also thrown around the idea that XCP > is an "appliance" not a distribution. Can someone give me a > legitimate technical definition of an appliance? My search for > "distribution vs. appliance" on Google brings up a washing machine > place. >You don''t log into the shell of an appliance, but just access its "Front End" features. In the case of XCP, that''s just using the API.> My second point regarded updates. It was suggested that the way to > deal with this is to reinstall. In a production environment this is > often not acceptable. I believe it would be worth the effort to find > a way to send out security updates without affecting Xen itself. >Yes, updates using yum would be useful, but would require specific repos. Remember, while XCP is Linux based, this doesn''t means it''s using an environment that is 100% compatible with its upstream provider (CentOS/RHEL I believe). Generally, to update XCP, you should just use the downloads from xen.org. Remember, if you don''t access the shell, nothing will be exploited. You shouldn''t really have the need to run your security scanner on the Dom0 of XCP. That''s just breaks the methodology of XCP being an appliance. If you really want somthing to test with XCP, track and exploit the API used. I hope my comments help Oh and just to re-iterate, please firewall that box! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
***I''m reposting my post again with better spacing.***> Now, I am not intimately familiar with Xen, but are you telling me > that there is zero potential for dom0 to interact with any other > running VM? It cannot, say, read partitions allocated with LVM for > virtual machines? Cannot copy file that act as storage for the VMs? > Of course, the kernel cannot be patched in /boot either and the system > rebooted? None of these possibilities exist because of some unique > properties of dom0? I''m no Xen expert, so can someone can fill in > these blanks? >Sure it can. It is the "trusted Domain" after all. However, the reverse isn''t true. A DomU cannot access anything running on the Dom0 without going via a network. I think the bottom line is that if you want to use your Dom0 in the traditional sense (as in, use it like a "real" linux environment), then maybe XCP isn''t for you. You shouldn''t really need to log into the shell of XCP at all. If you are finding that you do, then maybe you should just install Xen with a CentOS Dom0 and work from there. If you don''t log into the shell, then you won''t be executing any binaries yourself, hense nothing can be exploited. It goes back to the Washing Machine concept. If you don''t plug your laptop up to the RS232 terminal of your TV/Washing Machine/Microwave/Kitchen Sink, then it can''t be hacked.> Another argument that has come up was that the network card on dom0 is > on a trusted network, now this is news to me. None of my research > showed this, and certainly for an assumption so critically important > it should be in enormous block letters when you configure XCP in case > you missed it like I did.You should nevel place a server management interface on a VLAN that is accessable from the internet. If you do, at least firewall the box!> In my usage scenario, this machine is going > onto the real Internet, no firewalls, no nothing.This comment is alarming. Usually, the phrases "real Internet" and "no firewalls" don''t go together is a huge cause for concern. I don''t think having no /etc/shadow is your biggest problem.... If you are scanning for a PCI DSS compliant environment, I suggest you switch off your network, go back to the drawing board, and re-evaluate your network topology.> I was completely > unaware that such assumptions of a friendly world were in place. >For a management interface, a friendly world is always assumed. Just having a password isn''t enough security. You shouldn''t give outside users access to a login prompt that they are able to log in as root with (that''s what VPNs are for). Also, if you''re doing a PCI DSS audit, any VPN used must be 2-factor, but this is OT.> Participants of this thread have also thrown around the idea that XCP > is an "appliance" not a distribution. Can someone give me a > legitimate technical definition of an appliance? My search for > "distribution vs. appliance" on Google brings up a washing machine > place. >You don''t log into the shell of an appliance, but just access its "Front End" features. In the case of XCP, that''s just using the API.> My second point regarded updates. It was suggested that the way to > deal with this is to reinstall. In a production environment this is > often not acceptable. I believe it would be worth the effort to find > a way to send out security updates without affecting Xen itself. >Yes, updates using yum would be useful, but would require specific repos. Remember, while XCP is Linux based, this doesn''t means it''s using an environment that is 100% compatible with its upstream provider (CentOS/RHEL I believe). Generally, to update XCP, you should just use the downloads from xen.org. Remember, if you don''t access the shell, nothing will be exploited. You shouldn''t really have the need to run your security scanner on the Dom0 of XCP. That''s just breaks the methodology of XCP being an appliance. If you really want somthing to test with XCP, track and exploit the API used. I hope my comments help Oh and just to re-iterate, please firewall that box! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Well, i `ll do my best, feel free to dig though my XCP`s, they are on 10.128.40.100-102. Regards r. On 05/11/11 00:29, Randy Katz wrote:> Riki, if you hack my TV I will call XCP my "appliance"! > > On 5/10/2011 3:05 PM, riki wrote: >> >> >> On 05/10/2011 10:46 PM, A Cold Penguin wrote: >>> >>>> Sorry I wasn''t completely clear. >>>> The reason why the use of /etc/passwd vs /etc/shadow is >>>> non-consequential is that XCP is a single user machine where all >>>> access is via UID 0. >>>> As such UNIX file permissions are effectively useless. For all intents >>>> and purposes 700 = 777 if you are always root and everything is owned >>>> by root yes? >>> .... >>>> Does this further clarify why changing to /etc/shadow would be of no >>>> consequence? >>> >>> >>> No, if anything, it makes even less sense. If all the daemons are >>> running as root, then the excuse that was put forward, that using >>> shadow would stop the necessary daemons from being able to perform >>> their synchronisation properly, is moot. >>> In the situation I am talking about here, root is often not used as a >>> super-user. Although it would be understood that in the requirement >>> of XCP this might be bypassed, the easy-access by keeping the >>> password in a world-readable file would not be acceptable. >> >> Is it possible to stop looking at the XCP as the unix-like >> distribution based on centos linux and start to look at it as a >> appliance. Are you guys evaluationg your microwave oven, fridge, NAS, >> set-top box and your smart TV? >> >> r. >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users >> > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
My two cents... (I''m not replying to any specific points, so have elided original msgs.) Xen is _not_ intended to do the same thing as VMware, Parallels, or other virtualization utilities running on a desktop or laptop. It doesn''t extend a "main" OS with extra capabilities. Instead, think of it as a management port on a blade server box, letting you move CPU chips, memory DIMMs, and disk cables between the blades. The hypervisor is the blade backplane. Dom0 only has two purposes in life: 1) run the lowest levels of the hardware drivers, 2) update the "firmware" binaries and configuration. Everything else, such as compilers to create the binaries, user management and authentication services, mail, web, file sharing, NTP, and _especially_ publicly accessible login/shells, should go on the "blades"--the domU''s. You could also think of the hypervisor/dom0 as a very weird router. Exposing this to the public makes operations people nervous for the same reasons that exposing a Cisco box''s management interface would. A very common model for this would be: -- Michael South msouth@msouth.org On May 10, 2011, at 23:39, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:> ***I''m reposting my post again with better spacing.*** > >> Now, I am not intimately familiar with Xen, but are you telling me >> that there is zero potential for dom0 to interact with any other >> running VM? It cannot, say, read partitions allocated with LVM for >> virtual machines? Cannot copy file that act as storage for the VMs? >> Of course, the kernel cannot be patched in /boot either and the system >> rebooted? None of these possibilities exist because of some unique >> properties of dom0? I''m no Xen expert, so can someone can fill in >> these blanks? >> > > Sure it can. It is the "trusted Domain" after all. However, the reverse > isn''t true. A DomU cannot access anything running on the Dom0 without > going via a network. > > I think the bottom line is that if you want to use your Dom0 in the > traditional sense (as in, use it like a "real" linux environment), then > maybe XCP isn''t for you. You shouldn''t really need to log into the shell > of XCP at all. If you are finding that you do, then maybe you should > just install Xen with a CentOS Dom0 and work from there. If you don''t > log into the shell, then you won''t be executing any binaries yourself, > hense nothing can be exploited. It goes back to the Washing Machine > concept. If you don''t plug your laptop up to the RS232 terminal of your > TV/Washing Machine/Microwave/Kitchen Sink, then it can''t be hacked. > > >> Another argument that has come up was that the network card on dom0 is >> on a trusted network, now this is news to me. None of my research >> showed this, and certainly for an assumption so critically important >> it should be in enormous block letters when you configure XCP in case >> you missed it like I did. > > You should nevel place a server management interface on a VLAN that is > accessable from the internet. If you do, at least firewall the box! > >> In my usage scenario, this machine is going >> onto the real Internet, no firewalls, no nothing. > > This comment is alarming. Usually, the phrases "real Internet" and "no > firewalls" don''t go together is a huge cause for concern. I don''t think > having no /etc/shadow is your biggest problem.... > If you are scanning for a PCI DSS compliant environment, I suggest you > switch off your network, go back to the drawing board, and re-evaluate > your network topology. > >> I was completely >> unaware that such assumptions of a friendly world were in place. >> > > For a management interface, a friendly world is always assumed. Just > having a password isn''t enough security. You shouldn''t give outside > users access to a login prompt that they are able to log in as root with > (that''s what VPNs are for). Also, if you''re doing a PCI DSS audit, any > VPN used must be 2-factor, but this is OT. > >> Participants of this thread have also thrown around the idea that XCP >> is an "appliance" not a distribution. Can someone give me a >> legitimate technical definition of an appliance? My search for >> "distribution vs. appliance" on Google brings up a washing machine >> place. >> > > You don''t log into the shell of an appliance, but just access its "Front > End" features. In the case of XCP, that''s just using the API. > >> My second point regarded updates. It was suggested that the way to >> deal with this is to reinstall. In a production environment this is >> often not acceptable. I believe it would be worth the effort to find >> a way to send out security updates without affecting Xen itself. >> > > Yes, updates using yum would be useful, but would require specific > repos. Remember, while XCP is Linux based, this doesn''t means it''s using > an environment that is 100% compatible with its upstream provider > (CentOS/RHEL I believe). Generally, to update XCP, you should just use > the downloads from xen.org. Remember, if you don''t access the shell, > nothing will be exploited. > > You shouldn''t really have the need to run your security scanner on the > Dom0 of XCP. That''s just breaks the methodology of XCP being an > appliance. If you really want somthing to test with XCP, track and > exploit the API used. > > I hope my comments help > > Oh and just to re-iterate, please firewall that box! > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
[Argh... Hit send before the end.] A common, good security model is: Big bad Internet <==> Outer Firewall <==> DMZ <==> Inner firewall <==> Corp. Server subnet <==> User firewall <==> Corp. User subnet And a seperate subnet for management interfaces. To allow ops to control the net, there is a really hardened login server with login interfaces on the DMZ and corp users subnets and which forwards sessions to the management subnet. It should have two-factor auth, a very limited set of allowed users, etc. ---- An "appliance" is a single-purpose box with limited capabilities, such as a file server, print server, logging server, console server, etc. It should be very stripped down--crude or no graphics, primitive editing, very few daemons. A "server''s server." I wouldn''t classify anything with a "desktop" version of a package as an appliance. Good dom0''s don''t need anything other than Xen daemons, HW monitoring daemons, and maybe a log file rotator. All of this must be run as root. Adding any other, unnecessary users lessens security. Since all processes are root, putting the password in a separate file is pointless; it''s still readable by root. Getting rid of shadow files also allows you to get rid of vipw and vigr, elimininating two more potential sources of bugs. vulnerabilities, and updates. In this case, adding a shadow file will not actually increase security. The best it could do would be to provide "check the box" "warm and fuzzies" for people who do not understand shadow''s purpose. As such, it would be a _false_ sense of security. This may be the case here; "if I have shadow files, then it''s safe to expose the dom0 login to the bare internet." ---- Sorry for the long-windedness :) -- Michael South msouth@msouth.org _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> In this case, adding a shadow file will not actually increase security. The best it could do would be to provide "check the box" "warm and fuzzies" for people who do not understand shadow''s purpose. As such, it would be a _false_ sense of security. This may be the case here; "if I have shadow files, then it''s safe to expose the dom0 login to the bare internet."I don''t believe this, rather I believe that if any daemon has a problem at all... literally anything since it''s globally readable... the hash can be exposed. I think that the discussion started to go onto a tangent on security of management interfaces and all of these topics which are indeed important, but tangential. The security of the system is now determined by the lowliest application, some defunct Perl script running as "nobody" can now expose a password hash. Yes, as we discussed, we can isolate the network. But I think you all have to see that even with it isolated, the problem is still there. As evidenced by this thread, there is quite a bit of good information on "how Xen is meant to be used" which was not evident to me in the documentation that I read. I think that a nice wiki page on "best practices" or "suggested setup" could convey to the rest of the world what you have taken the time to convey to me. Heck, someone can probably write a nice article based on some of the ideas brought up in this thread. This would do a lot for others who are looking at Xen as I was. I still will not budge on the problems with /etc/passwd. I understand the evidence and arguments presented. However, the issue is that any user (I''m talking system users, not people here) can get access, even if it is on "the internal network". We have discussed the need to separate a potentially insecure interface from the "big bad Internet", and I agree fully with this. However, in my view there is still a problem. It''s like saying "yes, yes... if you ping the system it will email you the password... but we don''t allow ping see, we put it on a separate isolated network where ping is not allowed... where do you see a problem?!" I believe, personally, this is avoidance of a problem, and when it comes to open-source software I think problems should be confronted, that is why I am here. Regarding updates, could it be that shifting XCP to a Debian-based distribution will help? I admit I have some bias, since I prefer Debian-based distros (although I did have a fling with Gentoo for a few years, but it''s over between us). Should we, perhaps, make a concerted effort to adjust XCP to be a hardened distro rather than just a fork of something put out by Citrix? This discussion likely belongs on the devel list, but I just wanted to put it out there. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
If you run any Perl scripts, or anything that can usefully be ''nobody'', on dom0, then you''re doing it wrong. Create a domU and run it there. Doing it the other way around is like using the wooden part of a hammer to pound nails, then complaining that it''s a lousy tool. If your proposed application _really_ needs to hit those nails with a long skinny thing, then use a differemt tool, like a lead pipe. But try to keep an open mind--you''re going against the collected wisdom of lot of people''s experience. That said, it''s your (and your employer''s) neck. If you really want a full-fledged "main OS" with some secondary VMs slotted in, you might want to look at KVM. It provides an easy way to use QEMU to do that. Most of the popular distros imclude KVM packages. -- Michael South msouth@msouth.org On May 11, 2011, at 16:45, Adrien Guillon <aj.guillon@gmail.com> wrote:>> In this case, adding a shadow file will not actually increase security. The best it could do would be to provide "check the box" "warm and fuzzies" for people who do not understand shadow''s purpose. As such, it would be a _false_ sense of security. This may be the case here; "if I have shadow files, then it''s safe to expose the dom0 login to the bare internet." > > I don''t believe this, rather I believe that if any daemon has a > problem at all... literally anything since it''s globally readable... > the hash can be exposed. I think that the discussion started to go > onto a tangent on security of management interfaces and all of these > topics which are indeed important, but tangential. The security of > the system is now determined by the lowliest application, some defunct > Perl script running as "nobody" can now expose a password hash. Yes, > as we discussed, we can isolate the network. But I think you all have > to see that even with it isolated, the problem is still there. > > As evidenced by this thread, there is quite a bit of good information > on "how Xen is meant to be used" which was not evident to me in the > documentation that I read. I think that a nice wiki page on "best > practices" or "suggested setup" could convey to the rest of the world > what you have taken the time to convey to me. Heck, someone can > probably write a nice article based on some of the ideas brought up in > this thread. This would do a lot for others who are looking at Xen as > I was. > > I still will not budge on the problems with /etc/passwd. I understand > the evidence and arguments presented. However, the issue is that any > user (I''m talking system users, not people here) can get access, even > if it is on "the internal network". We have discussed the need to > separate a potentially insecure interface from the "big bad Internet", > and I agree fully with this. However, in my view there is still a > problem. It''s like saying "yes, yes... if you ping the system it will > email you the password... but we don''t allow ping see, we put it on a > separate isolated network where ping is not allowed... where do you > see a problem?!" I believe, personally, this is avoidance of a > problem, and when it comes to open-source software I think problems > should be confronted, that is why I am here. > > Regarding updates, could it be that shifting XCP to a Debian-based > distribution will help? I admit I have some bias, since I prefer > Debian-based distros (although I did have a fling with Gentoo for a > few years, but it''s over between us). Should we, perhaps, make a > concerted effort to adjust XCP to be a hardened distro rather than > just a fork of something put out by Citrix? This discussion likely > belongs on the devel list, but I just wanted to put it out there._______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
The only way somebody can access that file in the dom0 of XCP is if they already have the root password and are logged into the XCP dom0 as root. As several of us have already explained, the dom0 in XCP is a special part of the appliance. The dom0 is not intended to be used for running random Perl scripts or letting multiple users log in. Use a domU for doing those things. Also, in your comment, you use Xen and XCP interchangeably. Xen is part of XCP, but Xen and XCP are not the same thing. -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Adrien Guillon Sent: Wednesday, May 11, 2011 3:45 PM To: Michael South Cc: Xen List; Jonathan Tripathy Subject: Re: [Xen-users] XCP: Insecure Distro ?> In this case, adding a shadow file will not actually increase security.The best it could do would be to provide "check the box" "warm and fuzzies" for people who do not understand shadow''s purpose. As such, it would be a _false_ sense of security. This may be the case here; "if I have shadow files, then it''s safe to expose the dom0 login to the bare internet." I don''t believe this, rather I believe that if any daemon has a problem at all... literally anything since it''s globally readable... the hash can be exposed. I think that the discussion started to go onto a tangent on security of management interfaces and all of these topics which are indeed important, but tangential. The security of the system is now determined by the lowliest application, some defunct Perl script running as "nobody" can now expose a password hash. Yes, as we discussed, we can isolate the network. But I think you all have to see that even with it isolated, the problem is still there. As evidenced by this thread, there is quite a bit of good information on "how Xen is meant to be used" which was not evident to me in the documentation that I read. I think that a nice wiki page on "best practices" or "suggested setup" could convey to the rest of the world what you have taken the time to convey to me. Heck, someone can probably write a nice article based on some of the ideas brought up in this thread. This would do a lot for others who are looking at Xen as I was. I still will not budge on the problems with /etc/passwd. I understand the evidence and arguments presented. However, the issue is that any user (I''m talking system users, not people here) can get access, even if it is on "the internal network". We have discussed the need to separate a potentially insecure interface from the "big bad Internet", and I agree fully with this. However, in my view there is still a problem. It''s like saying "yes, yes... if you ping the system it will email you the password... but we don''t allow ping see, we put it on a separate isolated network where ping is not allowed... where do you see a problem?!" I believe, personally, this is avoidance of a problem, and when it comes to open-source software I think problems should be confronted, that is why I am here. Regarding updates, could it be that shifting XCP to a Debian-based distribution will help? I admit I have some bias, since I prefer Debian-based distros (although I did have a fling with Gentoo for a few years, but it''s over between us). Should we, perhaps, make a concerted effort to adjust XCP to be a hardened distro rather than just a fork of something put out by Citrix? This discussion likely belongs on the devel list, but I just wanted to put it out there. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Michael South
2011-May-11 21:33 UTC
Improving XCP [was Re: [Xen-users] XCP: Insecure Distro ?]
Picking up on some of your other points: Yes, Xen documentation sucks big-time. For example, it''s impossible to find what boot methods are available (pygrub, pvgrub, etc.), what works with what, and what''s obsolete. Of course, saying "somebody ought to..." is a time-honored way of volunteering :) You up to it? Time, enthusiasm, and being able to work with people are more important than deep knowledge, IMHO. Further hardening of dom0 is a really interesting idea. For example, is there really any need for a shell? Any need for any users who can do a general-purpose log-in? All we want is to start, stop, monitor, and configure domUs. Even grub has a lot of extra junk in it. Talking about what we want is appropriate for xen-users, methinks. Xen-dev can tackle hiw to implement. What do folks think? -- Michael South msouth@msouth.org On May 11, 2011, at 16:45, Adrien Guillon <aj.guillon@gmail.com> wrote:>> In this case, adding a shadow file will not actually increase security. The best it could do would be to provide "check the box" "warm and fuzzies" for people who do not understand shadow''s purpose. As such, it would be a _false_ sense of security. This may be the case here; "if I have shadow files, then it''s safe to expose the dom0 login to the bare internet." > > I don''t believe this, rather I believe that if any daemon has a > problem at all... literally anything since it''s globally readable... > the hash can be exposed. I think that the discussion started to go > onto a tangent on security of management interfaces and all of these > topics which are indeed important, but tangential. The security of > the system is now determined by the lowliest application, some defunct > Perl script running as "nobody" can now expose a password hash. Yes, > as we discussed, we can isolate the network. But I think you all have > to see that even with it isolated, the problem is still there. > > As evidenced by this thread, there is quite a bit of good information > on "how Xen is meant to be used" which was not evident to me in the > documentation that I read. I think that a nice wiki page on "best > practices" or "suggested setup" could convey to the rest of the world > what you have taken the time to convey to me. Heck, someone can > probably write a nice article based on some of the ideas brought up in > this thread. This would do a lot for others who are looking at Xen as > I was. > > I still will not budge on the problems with /etc/passwd. I understand > the evidence and arguments presented. However, the issue is that any > user (I''m talking system users, not people here) can get access, even > if it is on "the internal network". We have discussed the need to > separate a potentially insecure interface from the "big bad Internet", > and I agree fully with this. However, in my view there is still a > problem. It''s like saying "yes, yes... if you ping the system it will > email you the password... but we don''t allow ping see, we put it on a > separate isolated network where ping is not allowed... where do you > see a problem?!" I believe, personally, this is avoidance of a > problem, and when it comes to open-source software I think problems > should be confronted, that is why I am here. > > Regarding updates, could it be that shifting XCP to a Debian-based > distribution will help? I admit I have some bias, since I prefer > Debian-based distros (although I did have a fling with Gentoo for a > few years, but it''s over between us). Should we, perhaps, make a > concerted effort to adjust XCP to be a hardened distro rather than > just a fork of something put out by Citrix? This discussion likely > belongs on the devel list, but I just wanted to put it out there._______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Thu, May 12, 2011 at 3:45 AM, Adrien Guillon <aj.guillon@gmail.com> wrote:> Regarding updates, could it be that shifting XCP to a Debian-based > distribution will help?Should be possible, but again, not as easy at it sounds. There''s a relevant thread on xen-devel: http://www.gossamer-threads.com/lists/xen/devel/205640?do=post_view_flat It should give an insight on why it''s not a trivial task.> I admit I have some bias, since I prefer > Debian-based distros (although I did have a fling with Gentoo for a > few years, but it''s over between us). Should we, perhaps, make a > concerted effort to adjust XCP to be a hardened distro rather than > just a fork of something put out by Citrix?Good idea, but again, not as easy at it sounds. An initiative like that would most likely mean someone has to do all (or at least most) the work (at least initially). For example, IMHO Xen Live CD (http://wiki.xensource.com/xenwiki/LiveCD) is very useful, but looking at both the wiki page and github no one (other than the author) is interested enough to contribute. -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Joseph Glanville
2011-May-13 12:45 UTC
Re: Improving XCP [was Re: [Xen-users] XCP: Insecure Distro ?]
Hi I agree strongly with this sentiment of "the documentation sucks". Recently I have been doing my best and answer questions on the lists and further my engagement in the Xen community and the next logical step for me is to tackle the seemingly impossible task of documentation. I think this applies more globally to Xen than to XCP - none of the Xen.org projects are adaquately documented at this point in time. Both user documentation and developer documentation is very sketchy at the best of times, and what is there is usually quite out-dated or is the left overs of a half baked research project that was never integrated into the Xen mainline tree. It doesn''t help that the Xen community praises configuration over convention (not saying this is a bad thing) as it makes documentation very difficult - mainly because we advocate customizability over set configurations. Documentation (for new users atleast) will be considerably easier when dom0 kernels return to being available in most distributions. On the hardening front I don''t think any further hardening is required if XCP is used exclusively as a virtualization appliance. If there is no shell access other than physical maintance and all authentication and authorization is handled via APIs that don''t have the breadth of a shell then attack vectors are minimal to start with. Though the kind of hardening I would recommend is far from what was suggested in the previous thread. Multi-user style hardening of the root account, filesystem and config files etc is not required. As partitioning the deamons up into seperate users and groups is mostly superficial. As ultimately deamons will have VMM access and thus compromising the dom0 OS isn''t required for most attacks to be considered effective. However it does have some merit by being able to restrict the impact of a vuln in one deamon from compromising other deamons. I think at some point in time XCP will need to have a focus session where these points can be discussed and a conclusion reached on what lengths the XCP developers are willing to go to further harden XCP without hindering feature and stability development. Joseph. On 12 May 2011 07:33, Michael South <msouth@msouth.org> wrote:> Picking up on some of your other points: > > Yes, Xen documentation sucks big-time. For example, it''s impossible to find what boot methods are available (pygrub, pvgrub, etc.), what works with what, and what''s obsolete. Of course, saying "somebody ought to..." is a time-honored way of volunteering :) You up to it? Time, enthusiasm, and being able to work with people are more important than deep knowledge, IMHO. > > Further hardening of dom0 is a really interesting idea. For example, is there really any need for a shell? Any need for any users who can do a general-purpose log-in? All we want is to start, stop, monitor, and configure domUs. Even grub has a lot of extra junk in it. Talking about what we want is appropriate for xen-users, methinks. Xen-dev can tackle hiw to implement. > > What do folks think? > > -- > Michael South > msouth@msouth.org > > On May 11, 2011, at 16:45, Adrien Guillon <aj.guillon@gmail.com> wrote: > >>> In this case, adding a shadow file will not actually increase security. The best it could do would be to provide "check the box" "warm and fuzzies" for people who do not understand shadow''s purpose. As such, it would be a _false_ sense of security. This may be the case here; "if I have shadow files, then it''s safe to expose the dom0 login to the bare internet." >> >> I don''t believe this, rather I believe that if any daemon has a >> problem at all... literally anything since it''s globally readable... >> the hash can be exposed. I think that the discussion started to go >> onto a tangent on security of management interfaces and all of these >> topics which are indeed important, but tangential. The security of >> the system is now determined by the lowliest application, some defunct >> Perl script running as "nobody" can now expose a password hash. Yes, >> as we discussed, we can isolate the network. But I think you all have >> to see that even with it isolated, the problem is still there. >> >> As evidenced by this thread, there is quite a bit of good information >> on "how Xen is meant to be used" which was not evident to me in the >> documentation that I read. I think that a nice wiki page on "best >> practices" or "suggested setup" could convey to the rest of the world >> what you have taken the time to convey to me. Heck, someone can >> probably write a nice article based on some of the ideas brought up in >> this thread. This would do a lot for others who are looking at Xen as >> I was. >> >> I still will not budge on the problems with /etc/passwd. I understand >> the evidence and arguments presented. However, the issue is that any >> user (I''m talking system users, not people here) can get access, even >> if it is on "the internal network". We have discussed the need to >> separate a potentially insecure interface from the "big bad Internet", >> and I agree fully with this. However, in my view there is still a >> problem. It''s like saying "yes, yes... if you ping the system it will >> email you the password... but we don''t allow ping see, we put it on a >> separate isolated network where ping is not allowed... where do you >> see a problem?!" I believe, personally, this is avoidance of a >> problem, and when it comes to open-source software I think problems >> should be confronted, that is why I am here. >> >> Regarding updates, could it be that shifting XCP to a Debian-based >> distribution will help? I admit I have some bias, since I prefer >> Debian-based distros (although I did have a fling with Gentoo for a >> few years, but it''s over between us). Should we, perhaps, make a >> concerted effort to adjust XCP to be a hardened distro rather than >> just a fork of something put out by Citrix? This discussion likely >> belongs on the devel list, but I just wanted to put it out there. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >-- Kind regards, Joseph. Founder | Director Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users