Patchwatcher security improvements
dank at kegel.com
Wed Sep 10 13:50:28 CDT 2008
> The problem with your design right now is that you want to run the slave in
> some isolated environment and expect it to be secure. The build slave itself
> is a mission-critical process and putting it in a quarantine to run together
> with untrusted code allows malicious patches to interfere with its operation.
> This means an attacker can just kill it from inside his patch, causing the
> whole patch building operation to fail, or corrupt the baseline tree, or send
> hundreds of fake emails through the slave interface.
It can't directly send fake emails, since the build slave doesn't have
the email password, but it could certainly disrupt the build slave
and make it give bogus and malicious results. The design isn't for
security, it's for ease of prototyping and plugging in new build slaves.
> So I plan to run the build slave itself in a trusted environment, but make it
> quarantine individual build operations (similar to my previous design with
> user switching). This way the impact of an attack is highly limited - all it
> can theoretically do is fake his own patch results.
Yes, good, just please don't change the interface to the build master,
all your changes should be encapsulated in a custom build slave.
More information about the wine-devel