Intro

This page is intended for the sysadmins and/or site computing security who suddenly find themselves with someone in their office who wants to run elements of the xrootd system on their machines.

After the initial response of "Huh? What the !%@%# is xrootd?", for which answers can be found in the xrootd web pages, most admins and/or site computing security people will have a set of security related questions.

This page collects answers from the primary developer, Andy Hanushevsky, to some sets of questions which have been sent. If you have xrootd-related security questions not covered below feel free to send them to the mailing list.

Questions from Nick White - RAL

Will we get source RPMs so that we can compile xrootd per OS?

Both a source rpm and a simple source tarball are made available with each xrootd version.

Will we get binary RPMs, which are OS dependent?

The source RPM's and tarballs are always provided. The binary RPM is provided solely for convenience, but will typically be available for the most common platforms in use at high energy physics sites.

How will security issues with xrootd be handled?

As for security patches; that would be handled as any other patch.

A new version will be produced and announced on the mailing list. How the new version is distributed and deployed withing the site is up to the local sysadmin. As the clients are intentionally designed to be fault-tolerant against server restarts, deployment of new versions (with security fixes, for example) should be possible without complicated scheduled outages.

Let me elaborate on a related topic. The current xrootd supports Kerberos 5 authentication. CERN is quickly providing additional security mechanisms (GSI, etc). I doubt there will be many authentication types that are not supported. Additionally, security is handled via a plugin mechanism. So, any site can easily add whatever authentication is relevant to them. The enhanced filesystem support comes with an authorization package. While not a plugin, it is a separate linkable library.

Who will be responsible for patching xrootd?

What dependencies does xrootd have such as compilers, linkers, OSes, glibc, Java, etc....?

We have gone out of our way to make sure that the server side does not depend on any third party packages and is compiler and OS agnostic.

Are there web pages that hold security info?

See the pages linked from the main xrootd page.

Questions from Gary Buhrmaster - SLAC computing security

There are a number of good books on how to write secure code. Which is the one the developer uses as a guide?

The author uses his in-depth experience in the security field (e.g., author of side-car and virtual smart card) as well as numeous seminars and courses on security to guide his work.

What account does the code run under? Does the code drop all capabilities (on platforms where capabilities exist) after startup?

It only runs under a non-privileged user (though I suppose it should verify that it is not being run as root -- though you get what you ask for). We have not seen any platforms that we support where dropping capabilities is an option in a portable fashion.

What trust relationship does that account require outside the local machine for full functionality of the product?

Currently, host-based authentication and admin control. Not great but ok for now. Future plans for strong authentication where it makes sense (e.g., cross-domain services).

Was the code written with security or functionality as the highest priority?

Yes in the sense that security competed on equal footing but was never compromised to meet another goal.

Has the code been independently audited for security issues (for example, use of strcpy, snprintf, system, and appropriate checking input parms for sanity before using them, etc)?

No.

What code review process occurs to insure that new proposed features or changes do not compromise security?

None.

Is the code GPL'd, or does it have usage and/or (re)distribution restrictions?

It is distributed under a Berkeley-style license.

Is the code possibly encumbered based on any developer(s) having any previous access to any proprietary source code or information and insights made available under NDA (once tainted, there is no way to untaint an individual, which means that others may not be able to view xrootd code either, even to verify its security status, without losing their ability to provide code in the future)?

None to my knowledge.

What authenticators are available, and which ones have been demonstrated in a production environment? What sites?

Kerberos 5 here and at CERN.

Is the protocol proxyable and firewallable with commercial products (including load balancers), including their authentication/authorization mechanisms? Does it support socks?

The protocol is proxiable and firewallable. It does not support socks.

Does the protocol support/require full data encryption?

Support, yes (never implemented); require no.

Does the protocol support/require encryption for authentication/authorization?

Depends on the authentication method.

Does the protocol support/require data integrity validation?

No.

What authentication, authorization and resource allocation schemes exist to insure site policy is enforced both with and without proxies and front-end load balancers.

A general authorization package is available and is site optional. SLAC has not chosen the option.

What local/remote management services are provided (stop, start, ?)? How are they authorized?

Full fledged services available. Strong authentication required.

What local/remote instrumentation is supposed? How are they authorized?

Monitoring. No secure information is made available. Information can be freely obtained.

What connection/application throttling is implemented to insure that (D)DOS attempts will not succeed against the server?

Server will delay socket communication and break requests into mangeable pieces.

Why would I want to offer remote root access for anyone, I thought that was wuftp's job (bad joke due to a VERY confusing choice of name for the underlying programs - not your fault)?

Not my idea.

Who are the complete list of developers who have contributed code, and which was assigned as the security review engineer?

So far me (Andy Hanushevsky) and Heinz Stockinger. I was responsible for the security review (OK not independent but that's all we had).

For xrootd, what security weaknesses in the protocol/program are the developers aware of?

The only weakness is that sites can select to run without security (i.e., it's not enforced but has to be configured).

What percentage of future time will the developers spend reviewing code for security issues?

It's constantly ongoing.

What is a "best practice" configuration for maximum security?

Strong authentication and full access control.

What other sites have implemented xrootd, and who are the site security officers that I can talk to to understand what process they followed to review and approve the product?

IN2P3, CNAF, INFN-Padova and RAL. We never asked.