Lock Down a linux laptop
Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Lock Down a linux laptop

  1. #1
    Member
    Join Date
    Jan 2005
    Posts
    35

    Lock Down a linux laptop

    Ok....I have pretty much done what needs to be done and the I was required to do (I hope) but the one thing I am having problems with is locking down the GUI so no one can get into the other screens behind it. I have password protected it...but I don't want anyone else to be able to load anything on them.

    Does this make sense? I am referring to the other screens apps can be running in if you hit the cnt'l-alt-F1 keys together to get another screen (hit any of the function keys I mean). Only one screen gets you into a DOS looking area, another a GUI area where my app is running but the other areas I was told need to be unaccessible as well. Is there a way to lock them down?

  2. #2
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    Yes, there is a way to lock down those 'virtual consoles'. But why?
    Every system I've seen just pops up a login screen.
    If you locked down your accounts then there's nothing to worry about.
    Heck, they can come in quite handy from time to time.

    Anyone with physical access to your laptop can crack it anyway.
    No matter how much effort you put into protecting it.

    But if you really want to, have a look at /etc/ttys.
    That's the place to do it on a FreeBSD system.
    I'm assuming linux is the same.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  3. #3
    Member
    Join Date
    Jan 2005
    Posts
    35
    Well I locked down the other accounts but when the users actually get into the gui area of the application...you can install anything in those areas. I was only able to lock down with passwords the DOS-ish area of the app with passwords and the gui. I want to make it harder for them to access that area. These people probably know a lot more about this kind of stuff then I do...I at least want to make it hard to access any area in which they can change the applications.

    As is I have already made it quite annoying. I made it to do anything you need a password and login for each area of my application.


    But those darn screens...I don't know what to do with.

    I was told to find a way to lock them down and when I googled it I didn't have that much luck.

  4. #4
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    Now I'm confused.....

    What linux distribution are you using?

    That GUI you talk about? You mean the X windowing system?
    XFree86 or X.org? Or is it something homemade or build into that application?

    Is that application running as root?
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  5. #5
    Member
    Join Date
    Jan 2005
    Posts
    35
    This is going to sound weird...but yes the app runs as root but to do anything I made it so you had to log in with a different username and password to every area of the app. Because the app won't run as anything else and I also put restrictions on each username. Also to get into the DOS area of the console you need a password and a username as well, you can log in as root if you really want to...or you can log in as one of the restricted users that I had created. I have a log in that will allow only DB maintenance or just viewing priveledges of certain areas...and limited admin rights.

    I don't know that much about linux or the application I have been learning as I go...I have also been changing the app a little bit. I take it to be tested out next week. But I was told to lock down the box without uninstalling anything and make it as much like their unix box that they had....this thing is annoying me because they changed the application so it isn't going to lock down the same and it is running on a different OS kinda. It isn't going on a network but the way it transmits stuff I think I have locked down enough. I will find that part out next week. The only thing left is locking out those consoles.

    Xfree86 is built into the application. But I am not sure if that is what they are using for the windowing system. The app confuses me, since I don't really know what it is doing and not all the services that are installed on the system are being run...and well the developer quit 2 weeks ago so it got thrust onto me.

  6. #6
    Member
    Join Date
    Jan 2005
    Posts
    35
    sorry i repeated myself a lot and yes it is a home grown app on top of red hat linux

  7. #7
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    I think you're going at it the wrong way.
    If that app runs as root anything you can do with that app will have root privs. If that app can start other programs, it can start a root shell. If the app can modify files, it could create a SIUD root shell (meaning any user can start it and instantly become root).

    Why don't you try and find out why that app needs root and fix that?

    NB Xfree probably isn't build into the app. My guess is the app is an X-Windows application. They've just fixed it so when the laptop starts it'll start X and the app will run instead of a regular destop. It's like some sort of kiosk setup.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  8. #8
    Member
    Join Date
    Jan 2005
    Posts
    35
    It boots into the gui no matter what. You can choose to change the console windows. I know I am probably annoying you with this. I apoligize. I was told to not change the app in anyway (which I kinda couldn't listen to with the changes they wanted made. I don't know enough about what the app is supposed to do to figure out why it would need to run in root mode. As far as I can tell it is supposed to communitcate with satellite radios and there is supposed to be no margin for error the application is supposed to be secure. I wish I could play with everything to get a better feel for how the app is supposed to work so I could figure out how to fix that other problem. But I don't know if I take a away the root access if the equipment and software won't work together as they are supposed to...did that make sense?

  9. #9
    Senior Member
    Join Date
    Dec 2004
    Posts
    137
    Hi. Your applications should not run as "root". Make them run under regular user accounts.

    You can reduce the number of virtual consoles by editing, try this:

    Question 2: How do I increase/decrease the number of virtual terminals in Linux?

    Answer:

    Virtual terminals rock. If you use X exclusively, you probably don't much care for this question, but read it anyway as it may include some information that applies in your situation.

    If you want the short answer, skip down to the Short Answer section.

    On my system I keep 11 terminals active (F1 through F11) with the twelfth being dedicated to X. In addition to those I use the thirteenth terminal for logging (see the next question/answer).

    The first process spawned on any (standard) un*x system is usually called "init". init is the parent of all processes (pid 0) and, under Linux, has the role of reading /etc/inittab and spawning off the appropriate processes to get your system into a usable state (and then keeping it there). For this discussion we are only interested in the spawning of getty's, which are the programs that give you your login prompt. If you read the inittab file you will notice a section that looks somewhat like this

    1:2345:respawn:/sbin/getty 38400 tty1
    2:23:respawn:/sbin/getty 38400 tty2
    3:23:respawn:/sbin/getty 38400 tty3
    4:23:respawn:/sbin/getty 38400 tty4

    I'll go ahead and break the first line down

    1 - id of the virtual terminal (vt) [1].
    2345 - in which runlevels this getty should be spawned. 1 and
    six are usually reserved for reboot and shutdown. Each
    distribution uses its runlevels differently. Check the
    inittab documentation for more information.
    respawn - tells init that if this process ever dies[2] to spawn a
    new copy.
    /sbin/getty - full path of the getty to run on this vt.
    38400 - bps rate of the terminal. This doesn't mean a whole lot
    for local terminals but needs to be set for serial
    devices (dial-in or dumb term). Mingetty will not have
    this option.
    tty1 - the name of the device in /dev/ to which the getty
    should attach.

    So now that I've filled you full of seemingly worthless information (and possibly misinformation), you're ready for the...

    Short Answer:

    Just add more lines of the same form as above. For example, if you currently have four terminals (as in the example above) to add a fifth you'd just add a line as

    5:23:respawn:/sbin/getty 38400 tty5

    Then make sure the /dev/tty5 device node exists. If not, you can either use the MAKEDEV command to create it or do it directly with mknod

    cd /dev
    mknod tty5 c 4 5

    Similarly, to remove getty's you can either delete the lines you don't need or set the second field to only spawn the getty in certain runlevels and then run in something different. In the example above, if I ran in X only mode (runlevel 5), only the first vt would be available.

    Now you need to make your changes take effect. A common misconception is that you need to reboot after changing the inittab to make the changes take effect. Hey! This is Linux. Just type "init q" and init will reread its config file (inittab) and spawn/kill to applicable processes.

    Note that each getty eats up a certain (small) amount of RAM. If you aren't using them, you may as well stop them (you should probably keep at least two around).

    [1] Virtual terminals are also called virtual consoles and the latter may actually be more accurate, but I typed "virtual terminal" first and I'm too lazy to change it

    [2] "dies" is a bit oversimplified, but it will do.

  10. #10
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    Originally posted here by earthbound4u
    I don't know enough about what the app is supposed to do to figure out why it would need to run in root mode. As far as I can tell it is supposed to communitcate with satellite radios and there is supposed to be no margin for error the application is supposed to be secure.
    Running an application as root will NOT make it more secure and/or more reliable. If anything it will make it LESS secure.


    I wish I could play with everything to get a better feel for how the app is supposed to work so I could figure out how to fix that other problem. But I don't know if I take a away the root access if the equipment and software won't work together as they are supposed to...did that make sense?
    My guess would be the app needs access to some /dev device. So it's probably just a matter of assigning the right permissions. Nobody bothered, because, hey, if I run it as root it works. Sounds like an MCSE'r installed it.....
    Oliver's Law:
    Experience is something you don't get until just after you need it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides