logging builtin commands and renaming for security

ampshock

ampshock

I wanted to see if I could rename builtin commands and/or log their uses for personal security hardening.
For example if someone else is at my console and they type 'cd /' then I would like to log what their doing.
Furthermore, if I could rename builtins so that I could type something like 'kd' which would work just like a the 'cd' command it would generally make the system more difficult for anyone else to use.
Thanks!
uname -a:
FreeBSD thinkpad.ampshock.com 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 r359923 GENERIC amd64
 
I don't think this is a good idea. I don't even want to think about the logging stuff as trying to do this in a way that can't be easily circumvented seems close to impossible. You could patch the shell, but then, someone could use a different shell. Doing it on the system level, there's no easy way to figure out someone actually uses a shell builtin.

As for renaming stuff, you could patch your shell here as well -- and as a side effect, break all the scripts.

IMHO, if you feel the need to "harden" your system, you should think about a lot of other things that make more sense. Make sure nobody can access the system unauthorized. Put services in jails with minimal necessary access. Make sure to always keep the system and ports (!) up to date. And so on ...
 
If someone sits down at your console, all your security precautions are already over. But let's speculate about what you want to do.

Logging? Most shells already do that, and keep the log in a history. I happen to use bash, you just type "history", and it shows you what you did:
Code: 
   24  [2020-03-19 22:32:15 -0700] cd Desktop/House/lr_eqmon
   25  [2020-03-19 22:32:17 -0700] hg pull
   26  [2020-03-19 22:32:21 -0700] hg update
   27  [2020-03-19 22:32:29 -0700] ./autoTest -i flow
   28  [2020-03-19 22:44:08 -0700] ./autoTest -i all noflow
   29  [2020-03-19 22:45:24 -0700] ls AUTOTEST.results/
   30  [2020-03-19 22:45:35 -0700] ./autoTest all noflow
   31  [2020-03-19 22:48:30 -0700] hg status
(those are results from a random window, I guess I was running tests on a bit of software after it got modified on a different branch).

Now, the history log is not an audit-quality log. To begin with, the user can remove or modify the log themselves. But it wouldn't be very difficult to create a new shell that does tamper-proof audit logging.

Renaming commands? Theoretically possible: Just cd to /usr/bin or /bin, and go to town. In practice, this would be a disaster. To begin with, all the system boot and operation scripts would break. Upgrades would become impossible (how would the upgrade know that you have renamed /bin/ls to /bin/adam_and_eve?). Any software that contains scripts or executes existing system binaries would break. I think this is a crazy suggestion.

Oh, and you can't rename the cd executable, because cd is a shell builtin command. Which is perfectly logical if you understand how the current directory and other process environment settings (like environment variables) work: cd (and setenv) have to be shell builtins, since there is no way for a program to change the current working directory of a shell from the outside. You could rename the /usr/bin/cd executable, but that accomplishes nothing (I don't even know when it is used or what it does, but it is not the normal cd operation).
 
If I was running a ssh server that happens to become vulnerable or it is just a honeypot... I am not familiar with how the shell works or how someone could use a different shell then what is provided. Could I save the oiriginal builtin commands into a backup directory and when I am using my computer load those but when im away from the computer and logging off then could I load the bogus builtins with renamed-names?
thank you Ralphbsz & Zirias
I'm not sure about how to patch the shell but

I was trying to read 'Unix Power Tools'
By Jerry Peek, Shelley Powers, Tim O'Reilly, Mike Loukides

I was trying to understand how bash evaluates the command line. Its pretty cryptic to me and I am not sure where to start..
It does sound like changing some of the builtin commands like 'cd' is a bad idea for upgrades and stuff.
 
Well, the source code for the shell is available (duh, the source code for nearly everything is available). Changing it to rename the builtins and recompiling would be "trivial", in the sense of time-consuming, but not intellectually challenging. If you were to build a honeypot for full shell access, starting with a modified shell would be a great idea.

But for builtin commands there is no "directory", and no "backup". They are compiled into the shell. You could achieve that effect by keeping the normal shell around, and creating a new "honeypot" or "weird" shell.

Understanding how shells parse the command line is (a) incredibly complex, and (b) necessary for full mastery of shell scripting and advanced shell usage. In particular, you have to know when the shell does which substitution, in order to get quoting correctly. I can never remember the details, and have to re-read documentation every time I need to go into the deep part of the shell.
 
Write your own shell and use chsh(1) to switch to it. After some experiments you may conclude this is a dead end but will give value in learning how shells work.
 
just replace the binary(the basic ones) like cp, cd, and put shell scripts in their place
but this is so dirty that I'have to wash my hands(no corona virus reference in any way)
after think of it...
for other part the source for cp,cd,etc is there in somewhere in the home of beastie
 
Elazar said:
To rename some builtin commands just edit the filenames in /usr/bin, /usr/sbin/
Click to expand...
In a quick search returns
/usr/src/bin/sh/cd.c
/usr/src/bin/cp/cp.c

some time ago I'modified the cp source to show the destination before that finish copy
 
There is an executable, /usr/bin/cd. Does anybody know what’s about it? It’s acting like builtin(1) cd, but doesn’t actually change direction.
E.g.:

/usr/bin/cd /

/usr/bin/cd /a
cd: a: No such file or directory

/usr/bin/cd -
cd: OLDPWD not set

/usr/bin/cd -v /usr/local
cd: Illegal option -v

I couldn’t find anything in /usr/src.
 
You must log in or register to reply here.
Back
Top