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?

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.

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.

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?

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.

sorry i repeated myself a lot and yes it is a home grown app on top of red hat linux

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.

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?

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:

Quote:

---

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.

---

Quote:

---

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.

Quote:

---

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..... :eek:

I am an MCSE... :(

Quote:

---

Originally posted here by rowdy_yates
I am an MCSE... :(

---

My condolences ;) No, I'm joking. I just don't hold that piece of paper very high.
I had to kick a few of those "profesionals" out of our serverroom because they were *****ing things up. And they all tend to run everything as administrator....(hence the pun)

It's a nice piece of paper to use..... on the toilet.. :D

Post deleted.

I didn't create the app...I was just told not to change or modify anything....and given that to secure it I needed to adjust some stuff I did do the foolish thing and ask one of the higher ups if I could fix that little issue but they said no.


I can't help what they don't want me to do.

I think that you have bigger problems than you think. What about physical security?

Hey if you can't trust the users not to mess with it, you shouldn't be letting them anywhere near it?

If they have physical access then they could use boot disks/CDs or whatever to crack your system?

And when your bosses will not allow amendments, it does not sound if they have clearly defined their objectives, or the "rules of engagement".

I don't know the politics, but I really think that you need to get this sorted out...........why did the original developer leave before the job was completed?

just a few thoughts ;)

The physical access of the machine won't be a problem when I finsih configuring it. It is in a secure lab that is monitored by cameras and other such lovely devices as well as a guard not to far away. Outside devices aren't allowed in the lab. Also I locked out the bios and the machine cannot and will not do a normal boot up with out a password. I never new you can triple lock out the bios/ boot area till I got to this machine. It is kind of funny. You need 1 password to get into the bios. One to boot up the machine and another if you want to boot from some other nifty device outside of the HD like the internal cd or disk drive.

Sorry I am just learning this stuff....Am a little proud. I haven't been doing this that long.

But I don't think the physical security is going to be an issue.

As for the developer....they told me it was a difference of opinion. And wouldn't go into it.

I just got hired here. I don't have the pull to ask much. So I am not going to snoop...but I can go around their requests. If I have to...actions first explain later kind of thing.