> The PR proposes (and the patch given earlier implements) tighter > security on the premise that security in the presence of KTRACE > should be at least as tight as without KTRACE. It achieves this > by requiring read permissions on an executable before it can be > KTRACE'd. As other have pointed out, if you're good enough to reverse engineer a program from just it's syscall, you're probably good enough to stick in a new shared library that allows you to 'reverse engineer' w/out requiring KTRACE. Again, security through obscurity is never a good solution, and this is just that wrapped in different clothes. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
- deny ktrace without read permissions? jkoshy
- Re: deny ktrace without read permissions? Greg Lehey
- Re: deny ktrace without read permissions? Nate Williams
- Re: deny ktrace without read permissions? jkoshy
- Re: deny ktrace without read permissions? Sheldon Hearn
- Re: deny ktrace without read permissions... Warner Losh
- Re: deny ktrace without read permissions? Nate Williams
- Re: deny ktrace without read permissions? Nate Williams
- Re: deny ktrace without read permissions? Sean Eric Fagan
- Re: deny ktrace without read permissions? jkoshy
- Re: deny ktrace without read permissions... Sean Eric Fagan
- Re: deny ktrace without read permis... Warner Losh
- yet more ways to attack executing binari... Robert Watson
- Re: yet more ways to attack executi... Chris Costello
- Re: yet more ways to attack exe... jkoshy
- Re: yet more ways to attack... Dominic Mitchell
- Re: yet more ways to attack... Nate Williams
- Re: yet more ways to attack... Chris Costello