BIND 10 #139: review: copy environment variables from bind10 to children

[BIND 10 Development]

#139: review: copy environment variables from bind10 to children
--------------------------+-------------------------------------------------
 Reporter:  jinmei        |        Owner:  jinmei
     Type:  enhancement   |       Status:  closed
 Priority:  minor         |    Milestone:        
Component:  Unclassified  |   Resolution:  fixed 
 Keywords:                |    Sensitive:  0     
--------------------------+-------------------------------------------------
Changes (by jinmei):

  * status:  assigned => closed
  * resolution:  => fixed


Comment:

 Replying to [comment:1 shane]:

 > However, I think we need to look at the BIND 10 security model in
 greater depth. Probably something to discuss in person and make an actual
 deliverable. So, rather than making the software harder for us to use for
 a poorly-thought-out "security" feature, go ahead and merge this change.

 Okay.  Then I'll simply close this ticket.  (It is already *merged* in
 that it's been committed to the trunk.  I have a question about the
 relationship among "patch", "review", "merge", "trunk", "release", etc, as
 I quickly raised this morning/afternoon/night, but that's a different and
 more generic issue)

 Now, commenting on the original rationale:

 > The intention was to run children with only environment variables that
 we set. This is in keeping with practice of things like cron. My thinking
 was that various types of attack are perhaps possible by running with a
 bogus environment - like setting strange LD_LIBRARY_PATH. ;)

 I don't think this trick buys much, if any, wrt security.  With this logic
 we couldn't even let shells delegate environment varialbes to child
 processes, could we?  After all, if a malicious guy tries to do some evil
 thing by setting LD_LIBRARY_PATH or whatever to a strange value and
 passing it to b10-xxx processes via the boss process, that person already
 has sufficient privilege to do that even with the previous model of env
 handling.  Besides, bind10 is "hackable" by default (right?) so the evil
 person could even rewrite or develop their own evil version of the boss
 program.

 I didn't know cron strictly limits inheritable env variables or whether
 it's for "security" purposes, but that might be because the cron daemon is
 supposed to invoke arbitrary program, often changing the owner of the
 process from a super user to an arbitrary normal user.  The relationship
 of the BIND10 boss process and other b10-xxx is pretty much different from
 this: invokable programs are generally fixed and hardcoded, and there
 would only be a few known variations for the owner of the child processes
 (a super user + user "bind").

 If we refer to other applications for an analogy, I think postfix is more
 appropriate than cron.  And, from a quick study of its source code the
 master process of postfix doesn't filter any environment variables for its
 children.

-- 
Ticket URL: <https://bind10.isc.org/ticket/139#comment:2>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development