Any IT manager needs to have exactly the following skills:
Ability to listen and understand his techies. This usually means he needs to have been an IT grunt at some point in his career.
Ability to take their advice and repackage it into something that he can present to the folks who sign the check
Ability to prevent anyone outside IT from intruding directly into the IT employee's time. Act as a gatekeeper unless specifically requested not to by a techie.
While we techies know our shit, too frequently we don't know how to explain it to the people who we're helping out, and seldom can do so to those who are going to give us the money to by the equipment we need. A manager who can keep us working happily by filtering innane problems to us rather than having us spend 100% of the time helping people move their mouse is the only way to keep us from jumping ship. And having the manager communicate our needs in the marketing speak that we don't have is the only way to get us our toys so we are happy in our jobs.
A good IT manager knows enough to understand the geeks, figure out when we're lying, and protect us from politics and direct moron access.
It's hard to be sure from the article itself (given that reporters are unlikely to understand the distinction, much less care), but in what way is this stack manipulation random? Quoting the article:
The group randomised where in memory the "stack" -- a structure that holds applications and their data -- resides, so that code designed to exploit buffer overflows will have to be tailored to the system's memory layout.
but this is still vague. It could be:
Per kernel. (All processes on this box have the same stack layout)
Per process. (All processes have a different stack layout, though threads and forked versions may have the same.)
Per binary. (Each program's stack layout is determined at compile time and will not change on invocation.)
Completely random (Each program is different every time, or better yet each function call is different each time.)
This would have a very import impact on how well a hacker could brute force your processes. If a given process always has the same stack layout then you can eventually brute force it, just like we currently can brute force offsets. The bar is higher of course - only one variable is being manipulated - and a hacker will probably go to easier machines before too long. But a truly randomized per process invocation or better yet per function call invocation would be such a moving target that it should be extreemly unlikely to succeed. I'm really excited.
Hopefully this should not be a problem. If you're drunk enough to be willing to sign someone's key without properly verifying everything, then you're probably too drunk to type your passphrase. You're certainly too drunk to read the 'gpg -h' output and remember what the command line switches are. You're more likely to end up signing a copy of some sensitive file and sending out to all your friends.
Slashdot Mirror
While we techies know our shit, too frequently we don't know how to explain it to the people who we're helping out, and seldom can do so to those who are going to give us the money to by the equipment we need. A manager who can keep us working happily by filtering innane problems to us rather than having us spend 100% of the time helping people move their mouse is the only way to keep us from jumping ship. And having the manager communicate our needs in the marketing speak that we don't have is the only way to get us our toys so we are happy in our jobs.
A good IT manager knows enough to understand the geeks, figure out when we're lying, and protect us from politics and direct moron access.
but this is still vague. It could be:
- Per kernel. (All processes on this box have the same stack layout)
- Per process. (All processes have a different stack layout, though threads and forked versions may have the same.)
- Per binary. (Each program's stack layout is determined at compile time and will not change on invocation.)
- Completely random (Each program is different every time, or better yet each function call is different each time.)
This would have a very import impact on how well a hacker could brute force your processes. If a given process always has the same stack layout then you can eventually brute force it, just like we currently can brute force offsets. The bar is higher of course - only one variable is being manipulated - and a hacker will probably go to easier machines before too long. But a truly randomized per process invocation or better yet per function call invocation would be such a moving target that it should be extreemly unlikely to succeed. I'm really excited.Hopefully this should not be a problem. If you're drunk enough to be willing to sign someone's key without properly verifying everything, then you're probably too drunk to type your passphrase. You're certainly too drunk to read the 'gpg -h' output and remember what the command line switches are. You're more likely to end up signing a copy of some sensitive file and sending out to all your friends.