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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
