SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
"Self, WTF good is the oh, so bitchin' xscreensaver SCREEN LOCK if any idiot could come along and make my X go POOF with a simple ctl+alt+BackSpace???" ...they would get dropped into my shell. You know, the shell where I started X? BAM Full Access.
How I solved this was I decided to make X start right up by changing /etc/inittab line "id:3:initdefault:" to say "id:4:initdefault:". Now if X is killed there is no open, vulnerable, naked little login-shell waiting to get sploited! =-)
Also, I found (like most astute slackware newbs) that when X starts, it listens on port 6000 for connections (XDMCP or whatever). This really bugged me, since I never plan on using this awesome feature.
So I edited /etc/X11/xdm/Xservers (I excluded KDE from my 13.1 install).
and changed this line
I thought the nolisten flag was standard for X and had to be changed to allow remote connections. I set X11 forwarding on ssh with a value of >/= +100: Port6000 for local connections, limit the users. Port6100 or greater for remote. Limit the users.
Isn't it also possible to change the key combination?
Yep, this is one of those little things that needs attention after installing Slackware. KDM adds "-nolisten tcp" by default when starting the xserver, but startx and xdm don't.
As for the screenlock, ctrl-alt-backspace and virtual console switching can be disabled from xorg.conf, or rather you used to be able to: I think you have to do it in HAL on a newer Slackware as it was changed - presumably because editing a single line in xorg.conf was way too simple and the Xorg guys needed to show how clever they could be!
You also have to be aware that alt-SysRq can be used to a similar effect, so it's not a good idea to leave an open console session on a Virtual Console as there's really no good way to secure it. screensaver/xlock only go so far.
I think it's worth mentioning that unless you have encrypted your disks (root,home etc), very few machines are secure when someone has physical access to them. Merely placing a live-distro CD in the tray and powering off and on will give you full access to everything not encrypted. A good firewall that closes all port other than SSH (22) would also prevent over-the-network attacks on X.