Wow, I just noticed it's been a year since I've blogged, that is not good.
That doesn't mean nothing has been going on though, we've been quite busy around here.
First I'd like to talk about a couple projects we are working on. The first is better integration of SELinux policies into RPM. We've posted a patch set to the rpm-maint [1] mailing list and are awaiting feedback. To try out the patches yourself you can read the instructions on the project page at selinuxproject.org [2].
The current patch set basically makes RPM actually do stuff with the %policy tag, which it never did before. We've also changed the %policy tag to be more flexible in allowing more information about the policies to be handled by RPM, such as policy modules that are being obsoleted. You can read the full description of the patches on the mail list postings [3].
This is only the first step in a long term project we have to make RPM more robust and reduce the amount of trust necessary in the package manager. We have several ideas of how to proceed but we haven't proven that they'll work yet (or that the RPM community will be interested in them). Suffice to say we basically want to break RPM into smaller pieces, each of which has a dedicated job to do, which can be confined by SELinux. Each step would require less trust that the packages aren't malicious and that the SELinux policy is correct and will enforce the security goals set forth by the packager. Once this is done we want to try running core parts of RPM in different security domains depending on different attributes about the package and who is running it, such as what certificates were used to sign the package, where the package came from, who is running RPM and so on.
The culmination of this effort would be to be able to download a 3rd party package and install it knowing that it will only be able to add its files to /opt, and not modify anything in /usr, /lib, /etc, etc. Further the scriptlets should be confined so that they can't add users to the system or any other security critical activities. This will be a truly exciting capability for Linux systems moving forward.
I delivered a presentation on this project at Linux Plumbers Conference last month in Portland. The slides [4] and video recording [5] are published on the web for those who are interested.
I'll talk about another project we are working on in my next blog post, which should be coming pretty soon.
Wow, I just noticed it’s been a year since I’ve blogged, that is not good.
That doesn’t mean nothing has been going on though, we’ve been quite busy around here.
I’d like to talk about a couple projects we are working on. The first is better integration of SELinux policies into RPM. We’ve posted a patch set to the rpm-maint mailing list and are awaiting feedback. To try out the patches yourself you can read the instructions on the project page at selinuxproject.org.
The current patch set basically makes RPM actually do stuff with the %policy tag, which it never did before. We’ve also changed the %policy tag to be more flexible in allowing more information about the policies to be handled by RPM, such as policy modules that are being obsoleted. You can read the full description of the patches on the mail list postings.
This is only the first step in a long term project we have to make RPM more robust and reduce the amount of trust necessary in the package manager. We have several ideas of how to proceed but we haven’t proven that they’ll work yet (or that the RPM community will be interested in them). Suffice to say we basically want to break RPM into smaller pieces, each of which has a dedicated job to do, which can be confined by SELinux. Each step would require less trust that the packages aren’t malicious and that the SELinux policy is correct and will enforce the security goals set forth by the packager. Once this is done we want to try running core parts of RPM in different security domains depending on different attributes about the package and who is running it, such as what certificates were used to sign the package, where the package came from, who is running RPM and so on.
The culmination of this effort would be to be able to download a 3rd party package and install it knowing that it will only be able to add its files to /opt, and not modify anything in /usr, /lib, /etc, etc. Further the scriptlets should be confined so that they can’t add users to the system or any other security critical activities. This will be a truly exciting capability for Linux systems moving forward.
I delivered a presentation on this project at Linux Plumbers Conference last month in Portland. The slides and video recording are published on the web for those who are interested.
I’ll talk about another project we are working on in my next blog post, which should be coming pretty soon.