Security wise any class could be loaded
because Xindice is a secure product... right... We are not talking about a security flaw here, because there is absolutely no security at all in Xindice.
Wait. I'm not saying that apart from XML-RPC Xindice was secure. I'm saying that the XML-RPC, as it stands now and has we kinda modified yesterday, has added a *major* hole to the system: from the Xindice POV there were no security holes, just information leak (you could read any document) and compromisal (you could delete documents) topped with potential DoS (you could write huge documents, run thousands of queries and so on).
This is, if we allow any class to be loaded dinamically at runtime, a real and proven security hole, which makes a huge difference, since this means that it's possible to execute arbitrary code. At least until now we had a (agreed, really minor and weak) protection due to the fact that the XmlRpc commands had to be under a package such as org.apache.xindice...: if we allow any class to be loaded at runtime this might become really dangerous.
Yes. But this is *really* dangerous too. Security wise any class could be loaded, since what is done is just a Class.forName(), with no checks at all. Find somehow your way to the server, put in the classpath i.will.hack.you.UA430wn3d with a bad execute(HashMap map) method (or don't really care about execute(), just use the default constructor to mess up things), call it via the XML-RPC interface and you're in. A bit too easy for my personal taste: there are too many Tomcats around running as root.
Let's paraphrase it: "find your way to the server, put in the classpath i.will.hack.you.UA430wn3d with a bad execute(HashMap map) method, modify the config-file, call it via the XML-RPC interface and you're in." I don't see how the config-file can protect you. Alternatively, you can put a new class "org.apache.xindice.server.rpc.message.Get", shutdown and reboot Tomcat and you don't even need to modify the config file.
That means that you are already 0wn3d with a shell account, which might not be the case. But putting a file on a server is not that hard, at very least it's easier than gaining remote shell access.
The user in this case is a sysadm that is supposed to know what she's doing.
Xindice is AFAIK still used by regular users and not ready for Fortune 100 companies.
Well, apart from the fact that regular sysadms are on average much better than the ones that run Fortune 100 companies :-), I don't think that "edit a config file if (and only if) you are willing to add another XML-RPC command to Xindice" could be threatening to Joe User (actually Joe Developer for that matter). The default, and possibly embedded, configuration file will be OK for 99.9% of the users, and will be left untouched.
the first implementation might be rough, but then we might easily switch to something more robust
if the user has to change every config file with every new release, I don't call this an "easy switch".
That wasn't my point. What I wanted to say was "let's find a *stable* format for the XML configuration file and let's have a *first* rough implementation of the RPC interface that reads that. We can refine it later". But the configuration file remains the same, across releases (not to mention that it will be most probably hidden in the jar, like most *.roles in Avalon-based apps).
Heck, we'll have to think about security sooner or later, don't we? :-)
Totally agree. So let's think about it NOW. First implement an ACL-based
system and then see how we can integrate this security in the XML-RPC calls. Not the other way around.
Cool, are we really ready to tackle this now? I'm absolutely +1 to this, I think that security, and basic authentication, is a major issue as of now. I'm starting to wonder about a 1.1 release maybe postponed but with metadata and basic AAA in... I'd love that! :-)
Ciao,
-- Gianugo Rabellino
