This is a very good point and I agree that upstream developers should be involved in policy
writing but there are several issues with this.
1) A developer is usually working on new features and bug fixes and that is their main focus.
While it would be great if every project had someone like Dan Walsh or Chris PeBenito who
would just work on the SELinux policy for their project this is not the case.
2) Not everyone runs systems with SELinux integration. Right now the main distro for SELinux
integration and development is Fedore. If you want SELinux in Gentoo you need to use hardened.
Debian was one of the first distros to integrate SELinux and it works well but they are still
using a split strict/targeted policy. Ubuntu now has SELinux support integrated but they are
going in a different direction with respect to policy.
3) The upstream policy maintainers and Tresys provide what is called a reference policy which
everyone can use as a start. However each distro may patch the policy how they see necessary
for their particular needs. The Red Hat policy makes a lot of changes to the upstream policy.
This could potentially make policy development difficult.
That being said this is still a good idea and hopefully it can happen soon. The best start for
this would be to break each of the applications policies out into their own packages that ship
with the main application package. Recent developments in the toolchain have made this more of
a possibility. The issue now is to get people in each project that understand SELinux and how
to write policy for it.
Posted Jul 12, 2008 23:12 UTC (Sat) by jch (guest, #51929)
[Link]
> 1) A developer is usually working on new features and bug fixes and that is their main
focus.
While I'm grateful to learn what a developer is usually working on, a great many of us do
spend a significant amount of time ensuring that our software is secure. Any tools to help
would be welcome.
SELinux and upstream developers
Posted Jul 15, 2008 16:50 UTC (Tue) by dpquigl (subscriber, #52852)
[Link]
Perhaps my wording was off. I didn't mean to imply that developers don't care about writing
secure software or that security isn't in mind when developing but rather that if it comes
down to implementing feature X or writing SELinux policy chances are feature X is going to be
implemented first. Unless you have someone who's job it is to keep track of what is changing
in your project and update your SELinux policy accordingly, your policy will be an
afterthought. I'd be glad to be proved wrong on this but sadly based on what I've seen this
seems to be the case.