Exploiting Linux vulnerabilities 8128

GreyCloud

OK, got that.

Without a ~-.profile sounds nearer to what I was after. Two situations come to mind: 1) Larger scale multi-user, where the user does *not* own the computer, but the administrators may well take the view that what the user does in the home directory is up to them. This isn't really the case I'm referring to, as in that case you'll have administrators managing the thing, depending what security policy they element. 2) Smaller scale - not necessarily one user-one machine, but likely with few users, no administrator as such, and quite likely the user(s) do in fact own the whole computer, so can do with it as they please, not just the home directory but all of it. There's lots and lots of these, and more of them are running Linux as time pbuttes.

So what I'm after is not so much preventing a user from being able to update their ~-.profile, but preventing a program from altering it without explicitly having to get user interaction-authorisation - a bit like having to sudo to root, except to your *own* id.

Even more general than that - it's not updating .profile that's a problem in itself, or having it call programs already installed-available on the system. It's the possibility that code might put executables somewhere like ~-, and set it auto-run on login, without interacting with the user for permission. Makinghome non-executable might achieve the desired effect, but seems a bit too restrictive - it would be enough if it's possible to ensure that files written cannot be made executable without explicit interaction with the user, maybe along similar lines to su-sudo privilege escalation. Maybe it's not too much of an issue for us at present - it's much less serious than malicious code being able to dig an auto-restart program in to the system so that it executes regardless of who logins in (maybe before login), as is usually trivial to achieve on a Windows system.

However, perhaps we should be asking ourselves some of these questions, and acting on them if need be as Linux becomes more popular. Thinking about what malicious code needs to do for automated propagation, if it can be made non-trivial for attacking code to recursively set itself to execute on restart, then that interlock is one way to break the reproduction-propagation cycle - and everytime we do that it makes potential attacks liable to fizzle rather than explode exponentially. -- JPB