[HN Gopher] Preventing Log4j with Capabilities
       ___________________________________________________________________
        
       Preventing Log4j with Capabilities
        
       Author : justinpombrio
       Score  : 18 points
       Date   : 2021-12-26 21:02 UTC (1 hours ago)
        
 (HTM) web link (justinpombrio.net)
 (TXT) w3m dump (justinpombrio.net)
        
       | adfhadfignio wrote:
        
       | gianone wrote:
        
       | to11mtm wrote:
       | So, IDK what the Java world had that was similar, but in .NET at
       | one time they tried to solve this at the runtime VM level with
       | the concept of Security Permissions and trust levels. In
       | practice, this wound up being:
       | 
       | - Somewhere between too confusing/frustrating to developers
       | (especially ASP.NET ones, where often the escape hatch of
       | 'AllowPartiallyTrustedCallersAttribute' would get thrown around)
       | 
       | - Hard to manage from a per-app granularity standpoint.
       | 
       | Edit, hit the post button too early:
       | 
       | In any case, this behavior wound up getting changed to be a lot
       | more forgiving in .NET 4 (although, often in fact requiring the
       | removal of the aforementioned APTCA from your web projects,) and
       | IIRC it's gone in Core.
        
       | eska wrote:
       | It seems more practical to use BSD's approach of pledging once in
       | main that the process won't access the network. Parts of the
       | program that need different capabilities are isolated in their
       | own processes and communicated with using IPC. I don't think
       | people want to pass all kinds of capabilities around in every
       | function call.
        
         | MattPalmer1086 wrote:
         | Sounds better in general, but probably wouldn't help with
         | something like logging which would probably be used in all the
         | processes. Unless you want to make IPC calls for every logging
         | call.
        
           | vlovich123 wrote:
           | I don't know. It's not necessarily a bad idea because then
           | you have a single audit point for all logs and can see the
           | cost centralized in measurement tools vs it looking to be in
           | the noise and never popping up unless you have particularly
           | egregious hot spots.
        
           | vladvasiliu wrote:
           | > Unless you want to make IPC calls for every logging call
           | 
           | Isn't this more or less what ends up happening anyway? Sure,
           | from the application's perspective it's just a function call.
           | But usually, in the end, the logs are shipped to some central
           | location one way or another.
        
       | dkysang wrote:
       | Does this interact with or preclude operating system level
       | capabilities?
        
       | gnufx wrote:
       | Hear, hear. I've said at work that many, perhaps most, of the
       | security issues I've seen are at least related to ambient
       | authority. I never see these major issues trigger any deeper
       | thinking about the issues beyond the relatively shallow bug
       | causing the vulnerability.
       | 
       | (A subtlety here is that you may want authority to write to a
       | network filesystem.)
        
       | vsareto wrote:
       | Why should a programming language be limiting network access? Why
       | wouldn't we do this via the operating system?
        
         | jayd16 wrote:
         | It might be useful that some code in a single process have
         | access while other parts do not. How would you propose an OS
         | handle those cases?
        
           | vsareto wrote:
           | I don't think that's particularly useful though. A program
           | with requirements like that seems more likely to be split up
           | into two independent pieces.
        
             | Jweb_Guru wrote:
             | But that's not at all the case in practice. Logging is
             | intertwined with other program functionality.
        
         | yjftsjthsd-h wrote:
         | Programming language can know more about the program's
         | (intended) state at any given time. The OS can/should
         | frequently be involved, but even then you're frequently doing
         | something like pledge() from the program to let the OS know
         | when/how to restrict you. Doing it totally externally, like
         | SELinux does, is valuable but coarser-grained.
        
           | vsareto wrote:
           | Can you not use network namespaces on Linux to give a process
           | its own restricted network device and then filter that
           | traffic?
        
       | monocasa wrote:
       | Except the vulnerability was a stack up. The logger wasn't making
       | network calls per se, but passing requests to a component (JNDI)
       | that would obviously need network access. You'd have the same
       | root issue, it'd just manifest more as sort of a confused deputy
       | with a capability based model.
        
         | armchairhacker wrote:
         | It still passes. Because JNDI would require network access, so
         | log4j would also have to require network access or "disable"
         | the network capability.
        
       | the_arun wrote:
       | Ideally all egress network connections should go via NAT Gateway
       | & filters at NAT Gateway should have policies to say which
       | request can go out. Failures do happen in programming, we need to
       | have better guardrails ensuring security.
        
       | josephcsible wrote:
       | This approach reminds me of Haskell's effect systems.
        
       ___________________________________________________________________
       (page generated 2021-12-26 23:00 UTC)