package level sandboxing and isolation #3030
                  
                    
                      JanZerebecki
                    
                  
                
                  started this conversation in
                General
              
            Replies: 0 comments
  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment
  
        
    
Uh oh!
There was an error while loading. Please reload this page.
-
I'd like to collect ideas for isolation of packages from each other and sandboxing or restriction of their capabilities on the system.
Currently many install time actions for rpms require scripts and there are many directories where placing files can indirectly trigger running code as root.
The xz compromise did not use this route, but it was a case of malicious build scripts not being caught during the software distributions process. While library sandboxing would have prevented it, there would still then be one other way open for a package with a malicious build script that provides this library. It could influence the package build so that the resulting package runs malicious code as root on installation. There are many packages with too few people to review all of them in sufficient detail. But most packages luckily do not need to run code as root.
Previously a plugin to restrict scripts somewhat was added to rpm: #2666
A somewhat related discussion is preventing artifact modification after %build: #3009
I have described ideas how to prevent this: https://github.com/affording-open/package-sandboxing
Can rpm implement package level isolation? How? Should it? Alternatives?
Beta Was this translation helpful? Give feedback.
All reactions