Check root password changes done via single user mode

Daniel Peyrolon tuchalia at gmail.com
Wed Mar 4 22:53:12 UTC 2015


Hi everyone,

What about patching the actual function used to store the password?

Another option would be to write a rootkit and hook it to the syscall used
to open the password file.
It it's written with write permissions, just let that know to the system
owner somehow. (sysctl, writing a file somewhere...)
Besides, being a kernel module itself, it would be able to detect if the
system is in SUM, and thus activate itself automatically, if I'm not wrong.

Of course, that could be avoided simply by mounting the filesystem in a
live system and changing the password there.
Once again, the solution to that is encryption.

Someone will be able to correct me and provide us with more information,
but that's as far as I can get on this.

El mié., 4 de marzo de 2015 a las 19:12, Arthur Chance (<freebsd at qeng-ho.org>)
escribió:

> On 04/03/2015 16:38, zep wrote:
> >
> >
> > On 03/04/2015 11:35 AM, Ricardo Martín wrote:
> >> At this point you might want to review the original post again.
> >> It's a simple and specific request for comments about whether if its
> >> feasible to somehow flag a root's password reset in SUM.
> >> No more, no less.
> >>
>
> >
> > perhaps you should review the responses.    the short answer is 'sort
> > of, but not really the way you seem want to; also it's a bit of a fool's
> > errand and whoever pointed you down this path doesn't like you very
> much'.
> >
>
> I'd agree with that. :-)
>
> If someone has simply changed the root password and done nothing else
> it's trivial to detect that it's changed - the daily periodic password
> backup will do that and it's enabled by default. You might also be able
> to decide whether it happened during multi- or single- user mode based
> on the modification time of the password file.
>
> If the person who changed it doesn't want you to find out it's changed,
> you are going to have a learning experience.
>
> --
> Those who do not learn from computing history are doomed to
> GOTO 1
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-
> unsubscribe at freebsd.org"


More information about the freebsd-questions mailing list