 |
 |
Hi Lukasz, OK, my previous comments were only in reference to the xrootd.cf file not the etc/sysconfig. So, let's start with the latter. Yes, you are absolutely right but this is because etc/sysconfig effectively runs as root. That means you would need at least those privs to modify it as it can assume any identity. We talked about the solution here in the OSG meeting and there was no consensus (i.e. all proposed solutions made someone unhappy). The bottom line was that the etc/sysconfig bundled too much information together. Some should only be changeable as a privileged user (i.e. the runuser name) and others should be open to the admin (i.e. instance names and instances). The short-term solution was to leave this owned by root until a more satisfying solution could be found. Now, as for the xrootd.cf file, changing it has little practical impact in the sense that if you've compromised the xroot server than you already have everything that you would want to have. Changing the .cf file does not give you more and in fact makes it possible to catch the compromise (i.e. it would be to your disadvantage to change it). The OSG proposed solution to this is allow the specification of the runuser and the admin user as separate pieces of information during the install process if that is a concern. Andy On Tue, 7 Jun 2011, Lukasz Janyst wrote: > Hi Andy, > > I don't think that Brian means the daemon consciously modifying the > config file. It's more the case of an attacker modifying it (by > exploiting a buffer overflow bug or whatever) or a user saying > "all.export / r/w" in the config by mistake. In this case (since the > daemon is able to write to it's config files) it is possible to modify > it's config file to say: "xrootd.chksum md5 > /a/path/to/my/checksum/program/on/public/afs" which on server restart > for whatever reason will lead to a possibility of an arbitrary code > execution. > > Furthermore, since the xrootd-admin user is able to modify > /etc/sysconfig/xrootd and thus set the group and user account for the > daemon it is possible for him/her to impersonate every user on the > system (apart from root) which, with the possibility of the forwarded > kerberos tickets laying around, can grant him access to the AFS files > other users. These are huge security holes and an admin who allows for > this to happen should not be an admin at all. > > Cheers, > Lukasz > > > 2011/6/7 Andrew Hanushevsky <[log in to unmask]>: >> Hi Brian, >> >> I do understand that. What we found in practice is that typical admins pick >> a username for the daemon which then becomes the defacto admin account as >> well. This is largely done out of convenience since the daemon account owns >> all of the files and you need to be able to manage the files at times as >> well. Trying to juggle two or more accounts to do this is just a royal pain >> when you know quite well that the daemon never modifies the config file. >> Sometimes, in these things, we work against our best interests (on either >> side), sigh. >> >> Andy >> >> -----Original Message----- From: Brian Bockelman >> Sent: Monday, June 06, 2011 3:45 PM >> To: Andrew Hanushevsky >> Cc: Doug Benjamin ; Lukasz Janyst ; xrootd-dev >> Subject: Re: Ownership of configuration files in RPM >> >> Hi Andy, >> >> I'm not saying these files should be owned by root, I'm saying that the >> daemon shouldn't be able to write to its own configuration files as a >> standard security precaution. I.e., if the config files are owned by "abh" >> and the daemon runs as "xrootd", then I have no problem. >> >> There are other ways to attack this on Linux, such as using SELinux or bind >> mounts such that the xrootd process cannot access /etc. >> >> Brian >> >> On Jun 6, 2011, at 5:39 PM, Andrew Hanushevsky wrote: >> >>> Doesn't the OSG RPM do this already? I agree with Doug that this is >>> necessary at many sites. You can't always assume that everyone will have >>> root privileges or that the person that has root privileges will administer >>> everything. It's quite unrealistic as we found at SLAC and IN2P3. So, I >>> suppose either we get a +rpm or ATLAS recommends that the OSG rpm be used. >>> >>> Andy >>> >>> -----Original Message----- From: Doug Benjamin >>> Sent: Monday, June 06, 2011 1:17 PM >>> To: Lukasz Janyst >>> Cc: Brian Bockelman ; xrootd-dev >>> Subject: Re: Ownership of configuration files in RPM >>> >>> Hi Lukasz, >>> >>> There are several Tier 3 sites where the system administration (OS etc) >>> is separate from the >>> experiment software administration. Thus one needs to be able change >>> configurations on the fly. >>> this is not possible without root priv if root ownes the configuration >>> files. One possible solution >>> would be to have a separate rpm that can be run to change the ownership to >>> the same account that runs >>> the xrootd service. This way the original rpms installs everything with >>> root ownership, but the separate >>> rpm can make the change with a proper switch. >>> >>> Doug >>> >>> >>> Lukasz Janyst wrote: >>>> >>>> 2011/6/6 Brian Bockelman <[log in to unmask]>: >>>>> >>>>> Let's make this a switch someone can throw in the RPMs at build time >>>>> then: certainly it's not a recommended practice. >>>> >>>> Yeah, I will do this if it's really necessary but I would like to >>>> avoid having too many build switches because I would then have to >>>> build and distribute the packages with all the possible switch >>>> configurations. I would prefer to drop this altogether. Doug, do you >>>> really have a use case that depends on this? It seems to be very >>>> far-fetched. >>>> >>>> Lukasz >> >> >