Re: How can I lock down a Red Hat system?
From:Date: 07/27/02
- Next message: none: "public_html permissions vs. file security"
- Previous message: : "Re: Where can i find my Iptables script for the current Iptables configuration?"
- In reply to: JR: "Re: How can I lock down a Red Hat system?"
- Next in thread: Hal Murray: "Re: How can I lock down a Red Hat system?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 27 Jul 2002 21:10:07 +0200
JR wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote in message news:<3D3866A9.C9D4F252@daimi.au.dk>...
> > JR wrote:
> > >
> > > Also for the user that
> > > does know Linux I don't want the to be able to run command and get
> > > into konsole or what ever else.
> >
> > Why? If I were to use a public computer in a library I'd like to
> > be able to open a term and ssh to systems where I have an account.
> > Any reason why you want to prevent that? I could mention a lot of
> > other things people might want to do with a terminal, and I
> > really think it should be no problem. When the next user is going
> > to use the computer he just press CTRL+ALT+BACKSPACE and everything
> > the previous user has done will now be gone.
>
> "Some environments, such as kiosks, Internet cafes and enterprise
> deployments, demand that the user not have full access to all of KDE's
> capabilities in order to preclude certain undesirable actions. To
> address these needs, the KDE Kiosk project was launched to supplement
> standard UNIX permissions."
>
> This paragraph from the web site that Jason provided in his post sums
> it up. We (the IT Department) do not want to be visiting these
> machines each day to reghost them because someone decided to play
> around with important system files.
The filepermitions should prevent users from playing around
with any important files. And of course not all maintainance
needs to be done locally, some of it can be done remote.
> If I could be 100% sure that I
> could lock down the sytem so there is no way a patron could change
> these files I would talk to the others and see what their thoughts
> are.
You can never be 100% secure. Occationally security related
bugs are found. And since you want to keep the system free
from all local root exploits, this means keeping up with
security upgrades is a good idea.
On Linux and similar systems I can think of three types of
local root explots:
- Bugs in suid/sgid executables
- Bugs in runing daemons
- Bugs in the kernel
This means to avoid problems you should have as few suid/sgid
executables and runing daemons as possible, and you should
keep them up to date. The kernel should be kept up to date
as well. Actually the latest local root exploit in the kernel
involved suid executables, so a system with no unnecesarry
suid executables might not have been vulnurable.
Trying to secure a system by limiting the number of
applications the user can use is of course a possibility, I
tried to do that nine years ago with a Windows 3.11 system.
But this is just not easy, remember that you have all odds
against you. When a user is using a browser on your computer,
you might have that user cooperating with a webserver in the
other end towards getting the user a shell on your computer.
I don't expect the browser to be secure enough to handle this
threat. So in either case you need the security on a lower
layer. So I'd go for the security at the OS level and give
the user freedom on the application level.
> I think I need to mention that I am new into the Linux world. I
> have about about 4 months under my belt of dabbling with the OS.
I have five years of Unix experience and three years of Linux
experience, and I'm already hacking my own kernel. :-)
>
> If I remember correctly CTRL+ALT+BACKSPACE just restarts the GUI.
That is true.
> How would it change anything the previous user has done?
By changing/replacing the login manager. What usually happens
is that gdm will do some setup and then start the X server
and the login dialog. When one of the processes terminates
the other gets killed and both processes are restarted.
What happens when you press CTRL+ALT+BACKSPACE is that the X
server will shut down, which triggers the restart with a new
login dialog. It is at this point we need a program to kill
all the users processes, and delete all his files before the
users homedir is recreated and the user is automatically
logged in again.
> Also I would like to keep the system logged in.
Of course. It is possible to avoid the login prompt and
automatically log into the X window system.
> That is just one more step that
> the user won't have to do.
Of course a lot of this should happen automatically.
>
> As I have stated before I am trying to make this as "user friendly" as
> possible. Most, if not all, patrons can handle sitting down, looking
> at the desktop see a couple of icons and click on what they want.
A note on top of the monitor telling the user to press
CTRL+ALT+BACKSPACE before starting to use the computer
and before leaving it shouldn't be too hard to
understand.
>
> Of course I am open to all ideas. Keep them coming. :-)
OK, I'll just give you one more idea right now. You
probably want an easy procedure to install the computer
over the net from a server. It can be made as easy as
booting the computer from a floppy. This is a help when
you want to add more computers with a setup identical
to the first one. And it is also a help if a user some
day is able to trash your system despite your efforts
to secure it.
Of course you want to setup the BIOS to not allow boots
from floppy, so the procedure would be:
1) Enter BIOS setup with password
2) Allow boot from floppy
3) Boot from floppy to install
4) Enter BIOS setup again
5) Disallow boot from floppy
Probably you are never going to need this.
-- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:razrep@daimi.au.dk or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk
- Next message: none: "public_html permissions vs. file security"
- Previous message: : "Re: Where can i find my Iptables script for the current Iptables configuration?"
- In reply to: JR: "Re: How can I lock down a Red Hat system?"
- Next in thread: Hal Murray: "Re: How can I lock down a Red Hat system?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
