Hey Jakob, If I understand correctly, then two plausible ways of attacking a client are then: 1) Screw up the client's DNS resolution somehow (reference the rather serious DNS hijack that have gone on) and trick it to talk to an attacker's node. 2) Perform a MITM attack. Since we are basing this on a block access token, if someone takes your token, then they can read your sensitive data or do some nefarious writing of data.
If you are accessing HDFS over the WAN, (1) or (2) are plausible. If you are accessing HDFS over the LAN (and the attacker doesn't have physical access), perhaps only (1) is plausible. I've found, when working to call something "secure", you need a precise definition of your goals. If the goals for the "security initiative" include client access from outside a trusted network (some folks would argue there's no such thing), then this would go against the goals. I would guess most security officers would not give a thumbs-up to this model. Notice I started this email with "If I understand correctly" - that's not a rhetorical device, there's a very real chance I'm not understanding things correctly. Please correct me as necessary :) Anyhow, from your email, you don't seem to be asking questions about the security architecture, but rather the startup sequence. I fully support dropping privileges. To go further, is there a way we can use SELinux to provide any more protection (I've been dreaming lately of finding a student and funding to look at tightening down the security of the services runnign at our site)? Brian On May 14, 2010, at 6:25 PM, Jakob Homan wrote: > HDFS-1150 (https://issues.apache.org/jira/browse/Hdfs-1150), part of the > security initiative, is a rather big change to the way Datanodes are started > in a secure environment and the resources needed to start one. I want to make > sure the community gets a chance to review the approach we're taking - and > the rather innocuous title may not convey the change we're looking at. > > The jsvc approach we've taken appears to be working and we're going to > commit it to the Y20 branch, but more comments are certainly welcome. > > -Jakob > Hadoop @ Yahoo!
smime.p7s
Description: S/MIME cryptographic signature
