At 10:34 Uhr +0200 19.6.2001, Ethan Benson wrote:
On Tue, Jun 19, 2001 at 10:09:51AM +0200, Christian Jaeger wrote: > But if the passwd command doesn't itself have the rights to access > /etc/shadow but only the root login shell has (which only runs if > called through sshd), then the cracker would have to know your root > passwd before being able to change it. passwd not being able to update /etc/shadow would be a very bad thing since users would be unable to change thier own passwords. users need to be encouraged to change thier passwords, not discouraged.
OK, didn't think about normal users. But then I would suggest writing a passwd wrapper (or modified passwd command) having access rights to the files but requiring root users (better even *any* user) to be logged in via sshd (or console or other trust path).
i don't think you can really modify passwd to be that granular about ssh vs other methods of access.
What I'm thinking of is using the ppid of the current process to track it back (like pstree) until sshd (maybe requiring sshd being only three levels back (sshd-->rootshellwrapper-->shell-->passwd)) and from there until init (to make sure sshd was called by init). I'm not that used to C and linux system programming, so I don't know whether you can reliably detect the file (path or inode/filesystem) a process was started from. How do you do that under linux, only by reading /proc? Since 'ps' seems to do that it seems to be the usual way (hm, /proc isn't that old I think so there had to be another (better?) way before?). I'm relying on root not being able to modify the pid/ppid and the path/inode/filesystem info of a running process (without patching the kernel, which would be made impossible by lids by denying module loading and /dev/mem access).
I'll try to write such passwd and shell wrappers if I get enough time the next few days. (As I said I'm not that experienced and so would need your help auditing the result if I get that far.)
Instead of only trusting init-->sshd you could also accept the path init-->/bin/login (for logins at the console). Or even /bin/login or /bin/su if *not* called from init, under the assumption they don't have bugs.
In principle you could choose which of the binaries doing pam authentification you want to trust, and then trust each child process from these (of course you have to check first that they only start child processes if authentification has succeeded).
Maybe modifying insmod to (have the module loading capability but) only accept lids-protected module files would solve the original issue of this thread.
im still not convinced you could prevent root from sshing to himself.
(I don't understand what you mean.) Christian.