Eben King wrote:
> On Tue, 7 Mar 2006, Kwan Lowe wrote:
>
>>> My problem is with the mepis system because someone will shut the
>>> system down even though I have taken all the Icons off the desktop
>>> except firefox so whoever does it has to make an effort and it isn't
>>> just a mistake. What I would like is the system to boot up into
>>> firefox and if they exit firefox it would start up again in 10
>>> seconds. I don't even know if this is doable. Any ideas? TIA Maury
>>
>> A couple possibilities:
>>
>> 0) Don't even load a window manager. There's a linux-kiosk project
>> that has hacked twm to load instead of the wm.
>
>
> twm _is_ a window manager -- Tabbed Window Manager. It's a minimal
> wm, to be sure. It's not an environment like KDE or GNOME.
Er... twm has always been "Tom's Window Manager" to me. It's been there
forever, in every X11 release I've ever used. Not very user friendly,
but tiny.
>> Kill firefox and the X-server exits and respawns via inittab.
>
>
> I think you'd have to have _no_ window manager for that to happen, or
> have the wm tweaked so that it exits when FF does.
You can spawn a window manager in the background and use firefox as the
"session anchor".
Depending on how you spawn an "X session", there is always that one last
process that doesn't exit until the user wants to logout. Typically that
is the window manager, but doesn't need to be.
Here's an example that uses xinit to spawn a session:
$ cat EOF> ~/.xinitrc
#!/bin/sh
twm &
firefox
EOF
$ chmod 755 ~/.xinitrc
Now, as root, setup a kiosk script that spawns xinit (to start the X
server and spawn a user session from ~/.xinitrc):
# cat EOF > /usr/local/bin/kiosk
#!/bin/sh
xinit
EOF
then as root add a respawn line to /etc/inittab:
$ grep initdefault /etc/inittab
id:2:initdefault:
$ echo 'x1:2:respawn:/usr/bin/su icblenke -c "/usr/local/bin/kiosk"'
>> /etc/inittab
$ telinit q
Viola. There you are.
When the user exits firefox (the session anchor), the xinit will die,
causing the kiosk script to die, causing init to respawn the kiosk script.
You don't really need to use xinit if you don't want to...
Here's a solution that doesn't use xinit:
# cat EOF> /usr/local/bin/kiosk
#!/bin/bash
export PATH=/usr/bin:/usr/bin/X11:$PATH
X :1 -ac -nolisten tcp &
sleep 5
su - icblenke -c "export DISPLAY=:1
twm &
firefox"
EOF
# echo 'x1:2:respawn:/usr/local/bin/kiosk' >> /etc/inittab
# telinit q
This is about as simple as you can get. This is running X with no access
controls (-ac) and without a TCP listener (without access controls, you
really don't want a TCP listener for security reasons between kiosk
machines). Granted, this allows anyone else on that system access to the
X display via the Unix socket, but this is a Kiosk with only one user
logged in at any time, right?
>> 1) Remove execute permissions for /sbin/shutdown for group and other.
>
>
> Read too, else Joe User can copy it, make the copy executable and run
> that, or do "/lib/ld-linux.so<tab> /sbin/shutdown" no matter its
> execute permission.
>
> Could the following text be the cause of the mysterious shutdowns?
>
> from shutdown(8):
> ,--
> | shutdown can be called from init(8) when the magic keys
> CTRL-ALT-DEL
> | are pressed, by creating an appropriate entry in /etc/inittab.
> This
> | means that everyone who has physical access to the console keyboard
> can
> | shut the system down.
> '--
>
> Absent any obvious reason, I'd say you've been hacked. Check
> /var/log/messages* for things like "foo 'su'd to root" or "root logged
> in from bar", not long before messages like "system is shutting
> down". Do "last | head" and look for odd logins. Take network
> interfaces down "for testing" for a day or two one at a time and see
> if the shutdowns stop. Of course, if you take down the outbound
> interface, people will stop using it, so that's not a good test. But
> you can still check the wireless that way.
If you leave "Zap" (cntl-alt-backspace) enabled or session switching
back to VT mode, and leave cntlaltdel enabled in /etc/inittab, the user
is going to be able to reboot the box.
In a kiosk application, you probably want to disable VT switching and
set "No Zap".
I would look at /var/log/messages and /var/log/auth.log to see when root
was obtained or otherwise used to run something.
Barring that, you may need to start recording user sessions to see what
they're doing.
At a minimum, I would have the kiosk machines behind a hardened "admin
firewall" that you record packet traces and otherwise limit outgoing
traffic to maintain some semblance of control over machines that you're
trying to lock down. It would be wise to also log from the kiosk
machines to such an admin box to ensure the logs aren't modified upon
intrusion for later analysis.
- Ian C. Blenke <icblenke@nks.net> <ian@blenke.com> http://ian.blenke.com/
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:44:03 EDT