 |
 |
Hi Lukasz, The "all.export / r/w" is indeed an issue and the admin doing that should be shot since that exposes more than just the config file. Yes, making it impossible for the daemon to not change the config file does close that particular hole but that is likely not the only hole when someone does something like that. I suppose we could issue a warning or perhaps even forbid it. 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 >> >> >