| 1 |
On Monday 08 September 2003 07:33, Jan Krueger wrote: |
| 2 |
> -prevent ebuilds from modifying the life filesystem (from pkg_postinst for |
| 3 |
> example), portage is the only one allowed to do so. that means a real |
| 4 |
> sandbox over full ebuild time. the image is ready after src_install. |
| 5 |
> portage than puts the files at the right place. The ebuild itself can in no |
| 6 |
> way touch the live filesystem. there is no need for the ebuild to do so. |
| 7 |
> (putting the build system into UML would be a considerable option for this. |
| 8 |
> maybe oversized) |
| 9 |
|
| 10 |
Maybe? That's definately oversized. Making pkg_postinst sandboxed too would be |
| 11 |
cool, prevents some lame things from happening because someone was asleep |
| 12 |
when commiting an ebuild but thats it. It doesn't help against an attacker. |
| 13 |
|
| 14 |
If an rsync mirror (or the master tree) got compromised, you could just as |
| 15 |
easily modify the portage ebuild. Even with your further security |
| 16 |
enhancements, where the portage ebuild could only overwrite files belonging |
| 17 |
to a previous version of the package you're screwed. The next time you run |
| 18 |
portage (which is right after updating portage, as the emerge is |
| 19 |
automatically restarted after a portage upgrade, if other packages are to be |
| 20 |
updated) anything could be done, as at least the install part has to be run |
| 21 |
as root. Boom emerge has root and can do whatever it wants, even with all |
| 22 |
that pkg_postinst sandboxing. |
| 23 |
|
| 24 |
|
| 25 |
Alex |
| 26 |
|
| 27 |
P.S.: I dunno if you're still subscribed to gentoo-dev so I write to you and |
| 28 |
cc the list. |
| 29 |
|
| 30 |
|
| 31 |
-- |
| 32 |
gentoo-dev@g.o mailing list |
Archives