[Kde-kiosk] locking things down

[Waldo Bastian]

I know that both symlinks and files without write-permission will work in=
 KDE3=20
but I am not sure how they behave in KDE 2.2.x (and I don't have 2.2 arou=
nd=20
here to test). Anyway, if the .kde/share/config directory is owned by the=
=20
user he/she can delete files in that directory, even if he doesn't have w=
rite=20
permission to the file itself (many people overlook that, the same holds =
true=20
for directories). KDE 2.2 writes new files by creating something like=20
"kdesktoprc.gkfghks" and then moves that file to "kdesktoprc", so even if=
=20
kdesktoprc is non-writable it can still replace it with new contents.

Now the questions is, does it do that? In KDE3 it won't. But I don't know=
 for=20
sure what it does in KDE 2.2, so you should check that. It could be that =
it=20
checks the permission and refuses to overwrite if it doesn't have=20
write-permission, in that case symlinks will work too. If it doesn't chec=
k=20
for write-permission, it will replace files with restricted permission as=
=20
well as symlinks when writing out new contents.

(I think it checks for write-permission in KDE 2.2 because I recall=20
bug-reports where people had root-owned files in their config-dir that ma=
de=20
that they couldn't change their config)

In KDE 2.2 symlinks will not work if the user has write permission on the=
=20
destination file, in that case it will simply replace the symlink with a =
new=20
file. (In KDE 3 it will write into the symlink itself)

Hope this helps you,

Cheers,
Waldo

On Tuesday 19 March 2002 01:06 pm, Janyne Kizer wrote:
> I was also wondering about using symbollic links to the files that we
> are rc files that we are tweaking.  Thoughts?  Experiences?
>
> Janyne Kizer wrote:
> > Unfortunately I need to have my servers ready before KDE3 is likely t=
o
> > be out of beta
> >
> > This is what we are experimenting with now.  It may be way off base s=
o
> > please excuse me:
> >
> > Set things up
> > - remove screensavers from share/applnk/System/ScreenSavers/ and
> > /usr/bin (leaving Blank Screen)
> > - set up the KMenu the way we want in /usr/share/applnk directory and
> > the /etc/X11/applnk/
> > - copy the Star Office 5.2 menu items to
> > /etc/skel/.kde/share/applnk/staroffice_52
> > - copy appropriately tweaked files to /etc/skel/.kde/share/config
> > (kcmartsrc, kickerrc, kpersonalizerrc)
> > - tweak $KDEDIR/share/config/kdesktoprc, $KDEDIR/share/config/kdeglob=
als
> > - remove klipper.desktop from /usr/share/autostart/
> >
> > Lock them down
> > ~/.kde/share/config <- chmod 444 *
> > ~/.kde/share/config <- chown root *
> > ~/.kde/share/config <- chgrp root *
> >
> > chmod 555 ~/.kde/share/applnk/staroffice_52/
> > chmod 555 ~/.kde/share/applnk
> >
> > Basially, on the menus, we just don't want people to be able to write=
 to
> > the applnk directories (except for the Star Office mini-install).  We
> > want users to get the menus and kicker that we deliver.  I don't
> > particularly care if they customize their desktop a bit though.  For
> > example, we may want to allow some changes in the ~/.kde/share/config
> > directory, though.  For example, changing backgrounds, putting icons =
on
> > desktop.  That's pretty much it though.  I guess after writing this I
> > should change the permissions on kdesktoprc :-)
> >
> > Andreas Pour wrote:
> > > Martijn Klingens wrote:
> > > > On Monday 18 March 2002 19:14, Janyne Kizer wrote:
> > > > > I would love to hear how others have locked down their KDE
> > > > > installations.  We would like to lock down the kicker and menu.
> > > > > StarOffice seems to be complicating things a bit though.  If I =
get
> > > > > it working the way that I want before others post, I'll be sure=
 to
> > > > > post my setup.  I locked things down a bit *too* much last time=
 and
> > > > > I had some login issue :-)  Thanks again for this list.
> > > >
> > > > I think Waldo's new Kiosk framework in KDE 3 will allow you to lo=
ck
> > > > down most of the settings stuff. Much more complicated will be to
> > > > prevent users from accessing the shell, since there are a _lot_ o=
f
> > > > ways to launch external commands from a Unix app. No idea how (or
> > > > even if) you could lock that down.
> > > >
> > > > Martijn
> > >
> > > Make /bin/sh a link to a setguid pre-shell program that denies
> > > interactive shells and (1) compares scripts to a set of permitted
> > > scripts, and/or (2) only runs scripts that are owned by root and in
> > > some configurable PATH (/usr/bin, /bin, /opt/kde2/bin, etc.), and m=
ake
> > > the actual shell only executable by that group (i.e., "chmod o -x
> > > /bin/real_shell)?  Of course the admins would be in this special gr=
oup
> > > and so be able to execute shell commands.
> > >
> > > Just a thought.
> > >
> > > Dre
> > > _______________________________________________
> > > kde-kiosk mailing list
> > > kde-kiosk@mail.kde.org
> > > http://mail.kde.org/mailman/listinfo/kde-kiosk
> >
> > --
> >
> > Janyne Kizer
> > CNE-3, CNE-4, CNE-5
> > Systems Programmer Administrator I
> > NC State University, College of Agriculture & Life Sciences
> > Extension and Administrative Technology Services
> > Phone: (919) 515-3609
> > _______________________________________________
> > kde-kiosk mailing list
> > kde-kiosk@mail.kde.org
> > http://mail.kde.org/mailman/listinfo/kde-kiosk

--=20
bastian@kde.org  |   SuSE Labs KDE Developer  |  bastian@suse.com