On 3/20/14, Steve Litt of Troubleshooters.Com <littdom@gmail.com> wrote: > On Thu, 20 Mar 2014 12:44:21 +1100 > Zenaan Harkness <zen@freedbms.net> wrote: > >> > Yeah, when making a machine for a less technical or less >> > command-prompt comfortable person, I like to have it boot into GUI >> > via the desktop manager. But when setting it up for myself or for >> > people technically sharp enough to log in and then type >> > "startx" (and people you can trust with the command prompt), I like >> > to boot to the command prompt. >> >> When logging in at the Linux console (on current kernels at least), >> then running startx, there is a security problem: >> >> Anyone with physical access to your computer could: >> >> a) logout of your gui session (if it's not screensaver locked), taking >> them back to your command line, and depending on your settings of >> /etc/sudoers tty_tickets or respectively !tty_tickets setting - see >> man sudoers) might give them instant root access; >> either way, mischief may ensure. >> >> b) type Ctrl-Alt-F1 (for example), followed by Ctrl-C to kill your gui >> session, notwithstanding if you even have it gui locked >> >> >> SO: what to do? >> >> What I did for a while was: >> a) log in to Linux console >> b) startx; exit >> >> This way, when the gui (X in this case) exits for any reason, then the >> console shell session logs out automatically. >> >> That's fine, but requires more typing, and remembering to add the >> extra "; exit" command. >> >> So to optimize, simply put the sequency "startx; exit" (or similar) >> into a shell function - I use the name "se" since it's less to type :) >> >> So now I use: >> a) log in to Linux console >> b) se >> >> Happy and safe sessions to all, >> Zenaan > > Outstanding! I'm going to start doing that. Thanks. You're welcome. > What shellscript contains the se function on your system? My system is not relevant. The point is, it needs to be in one of your startup scripts. If you use the GNU Bash shell, then you might try ~/.bashrc Other shells might have different function declaration syntax, and different put-this-function-in-my-environment syntax. I have attached my ~/lib/libintrospect.sh file and added the se function to the bottom, so you can see how this works for bash, including a function which can be used to export all declared functions - you may of course only want to export one or two functions, but at least this shows you how to do that. I plan to tidy up my bash libraries and upload them - hopefully this year. > Of course, if a badguy has physical access, then you're pretty much > screwed anyway: If you don't have a bios password they can boot System > Rescue CD, mount your root partition, delete the x in the second field > of root's record (or your record if there's no root), log in, press > enter, log in, change the password to something they like, and have > their way with the machine. Of course. This is simply one extra layer of protection, and will only protect you against a quick-and-dirty type attach which might otherwise be done in just a few seconds. This script can prevent that type of physical-access attack, so it's much better than nothing. Enjoy, Zenaan
Attachment:
libintrospect.sh
Description: Bourne shell script