Summary: | portage-2.0.50-r3 on crack? | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Chris C. Blockschmidt <ccb921215> |
Component: | Sandbox | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | blocker | CC: | mrannanj, solar |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Chris C. Blockschmidt
2004-04-07 18:06:38 UTC
Never mind, problem was a unprivileged user process spitting out the right /tmp/foo_._bar-nnnnn.log at the right time and thereby confusing emerge to death. It is undecided whether to remove the offending user from the system or hire him as a security expert. Is it safe to use 2.0.50-r3 or should we stick with 2.0.50-r1 until a better fix is found? What's wrong with -r3? It detected someone messing around on your system. Well it did accept 5 out of 8 fake sandbox logs so it can't be that much more secure. And the algorithm used in this particular exploit was able to trip -r3 but not -r1. Why is it possible for a unprivileged user to kill a root process. Unhelpful error messages like this aren't helpful either. it didnt 'trip' -r1 because -r1 didnt do the detection ... and the race condition is small, but as you can see, doable, which is why the user didnt hit 100% of your emerge attempts in other words, it's quite possible that they were doing the samething but -r1 didnt care, it happily continued doing whatever it was doing ... we issued a GLSA about this but there are two real issues here ... (1) the fact that /tmp is used (but thats been filed elsewhere) (2) the error messages are pretty unhelpful |