On Mon, 26 Feb 2001 at 5:30am (-0500), Jerry Human wrote:
> Hello Everyone:
>
> This is about one of the biggest frustrations I've found with all
> flavors Linux. Practically every time I find a command or program I want
> to use, BAM ... Permission Denied. For instance, I lurk on this forum
> trying to learn from everyone else's problems. One of the things I've
> waited months for is a way to set the system time from a time server.
> Today I saw a message and reply about netdate => rdate. I immediately
> checked for the manpage on the RH box and it was there (I do appreciate
> Linux's "if it is installed, it has a manpage" practice). Great! I
> connected the RH 6.2 box to the 'net and ran rdate from the command line
> with -s -p and it worked ... sort of. It did check the time and print
> it. Then it returned: "rdate: could not set system time: Operation not
> permmited."
>
> And that's the way it is with practically everything. I originally
> installed Linux to learn C++ over a year ago but that has become
> learning to cope with an OS that constantly refuses to work. Yes, I am
> uneducated in the wims and ways of the Unices, I'm trying to learn. But
> there is no easy way without buying a library or taking classes, both of
> which I can't afford and have minimal time to dedicate since I work
> twelve hour shifts six days a week. I don't mind having to learn
> something new, in fact, I embrace it, I enjoy learning. But the
> manpages, the docs, anything I can read seems to leave out just enough
> that "it" still won't work. That's why I still have to check my email on
> a Windows box.
>
> Obviously, the problem above with rdate is permissions. Being a system
> function it must be run as root. However, all docs say "don't run as
> root except to perform system maintenance" and I ran it as a user, like
> a good student. But being the only user I need to run it as user, not
> root. Also obvious is that each command or program requires a different
> "permission" scheme for different circumstances.
>
> I have read about permissions in several manpages, info's and even got a
> copy of Linux Unleashed (Third Edition) and Linux In A Nutshell (Second
> Edition) but nothing ever hints when a permission conflict may arise or
> how to approach the problem. I'm also aware that the problems of
> security of a large network are vastly different from a single machine
> with one user or a small home network.
>
> So my question today is two fold: (a) where can I finally learn how to
> handle permissions in different contexts, and (b) how can I set up rdate
> to set the system time when run as user?
I don't know how to answer A cause well.. it's complex. You know that
already... and my answer to B may illistrate that. :) The core problem is
that setting the date is a privledge operation enforced on the kernel level.
So what ever way we find around it will require giving the normal user
enough elevated privledges to be allowed to set the date. Ideally we want
to give them 'just enough' to do that an no more. Theres not all that much
danger in being able to set the date but as these are general principles
we'll pretend there is. :)
# chmod 6755 `which rdate`
# ls -l `which rdate`
-rwsr-sr-x 1 root root 5148 Feb 5 2000 /usr/bin/rdate
Okay - now rdate is suid, which means that it will always execute with the
permissions of the file owner (root) regardless of which user is executing
it. This is easy, and not /toooo/ bad for a stand alone system - but very
bad practise. There is no controls on this at all - every user who has
access to the system now has the ability to set the system clock from
anywhere at any time.
$ rdate -p -s wildwoods
[wildwoods] Mon Feb 26 20:53:13 2001
$
Well, we could restrict it by setting the group, and then only people in a
particular group would be able to access the suid rdate command.
# chgrp wheel `which rdate`
# ls -l `which rdate`
-rwxr-xr-x 1 root wheel 5148 Feb 5 2000 /usr/bin/rdate
Now the rdate command is owned by group 'wheel'. Changing the owner or
group of a file removes the setid flag to stop you give privliges you didn't
meant to so we need to put them back. We also want to make sure that no one
who isn't in the 'wheel' group can access the rdate command so we use a 0 in
'other users' field of the chmod for 'no privledges'.
# chmod 6750 `which rdate`
# ls -l `which rdate`
-rwsr-s--- 1 root wheel 5148 Feb 5 2000 /usr/bin/rdate
$ groups
user
$ rdate -s -p wildwoods
ksh: rdate: cannot execute - Permission denied
.. oh, we're not in the wheel group so we need to fix that first.
# groups user
user: user
... so the user is just in their own group, no secondary groups. So we want
to add them to wheel.
# usermod -G wheel user
# groups user
user: user wheel
NB. If the user was already in a secondary group we would have had to list
that in the usermod command. If a group they are already in is not listed
they will be removed from that group.
$ newgrp wheel # or could just login again.
$ groups
wheel user
$ rdate -s -p wildwoods
[wildwoods] Mon Feb 26 22:03:37 2001
This is better now only a select few users can set the time - our control is
a little more fine tuned. But if i got your password I could login as your
user and set the date (or something more harmful if we were talking about a
different command) so that isn't so great.
With redhat we can restrict access to certain privleged commands to only the
user logged in at the console. The assumption here is well, they could
reboot and just set the clock in the bios, or use a boot floppy, or what
ever. (Normally - obviously there are ways to restrict those to but that's
not really relevent here.) Instead of giving extra privleges (suid bit) to
the rdate command we use the suid consolehelper program to give us access to
the command instead. It checks using pam (pluggabale authetication modules)
weither you are the locally logged in user and lets you access commands that
you would not normally be able to.
We setup a symlink between the command we're interested in (rdate) to the
consolehelper program, so it gets executed instead, and if it decides we're
allowed to it will execute the real rdate command as root from its new
location an sbin directory.
So first we move the real rdate into sbin and reset it back to 'normal'.
# mv /usr/bin/rdate /usr/sbin/rdate
# chown root:root /usr/sbin/rdate
# chmod 755 /usr/sbin/rdate
# ls -l /usr/sbin/rdate
-rwxr-xr-x 1 root root 5148 Feb 5 2000 /usr/sbin/rdate
Now we setup the symlink and touch a 'control' file to tell consolehelper
that the rdate command is allowed to be used in this way. We also need to
set a pam pam file so it knows what restrictions are in place. We'll use an
existing one setup for console helper - the halt config file.
# cd /usr/bin
# ln -s consolehelper rdate
# ls -l rdate
lrwxrwxrwx 1 root root 13 Feb 26 22:15 rdate ->
consolehelper
# ls -l /etc/security/console.apps/rdate
-rw-r--r-- 1 root root 0 Feb 26 22:17
/etc/security/console.apps/rdate
# cp /etc/pam.d/halt /etc/pam.d/rdate
# cat /etc/pam.d/rdate
#%PAM-1.0
auth sufficient /lib/security/pam_rootok.so
auth required /lib/security/pam_console.so
auth required /lib/security/pam_pwdb.so
account required /lib/security/pam_permit.so
Now if our unplivledged user is the console owner...
# cat /var/lock/console.lock
user#
.. and is logged in at the console, that is a local X display or a real vt
(not a pty) then they should be able to use rdate after proving they really
are themselves. :)
Are we on the console? Yep.
$ tty
/dev/tty1
The 'real' rdate won't let us set the date.
$ /usr/sbin/rdate -s -p wildwoods
[wildwoods] Mon Feb 26 22:26:09 2001
rdate: could not set system time: Operation not permitted
But the 'cosnolehelper' rdate will once we give it /our/ password (not the
root passwd)
$ /usr/bin/rdate -s -p wildwoods
Password:
[wildwoods] Mon Feb 26 22:26:17 2001
$
Now we've got it under PAM's control there are all manor of things we can do
to futher narrow or expand the access controls. Asking our password is a
bit annoying, being as we're already logged, so lets get rid of that. If we
remove the line from /etc/pam.d/rdate that referes to pam_pwdb.so (the pam
password databse module) we won't be asked any more. So...
# cd /etc/pam.d
# cat rdate
#%PAM-1.0
auth sufficient /lib/security/pam_rootok.so
auth required /lib/security/pam_console.so
auth required /lib/security/pam_pwdb.so
account required /lib/security/pam_permit.so
# vi rdate # or the editor of your choice.
# cat rdate
#%PAM-1.0
auth sufficient /lib/security/pam_rootok.so
auth required /lib/security/pam_console.so
account required /lib/security/pam_permit.so
Now being on the console should be enough.
$ tty
/dev/tty1
$ /usr/bin/rdate -s -p wildwoods
[wildwoods] Mon Feb 26 22:28:48 2001
... yeah!
There are more solutions. There's an application called 'sudo' that works
in a very similar way to the consolehelper program except it doesn't use pam
- it has it's own database of users, and commands they are allowed to run as
root. This is actually the way I recomend you go becuase the documentation
is good and the program is simple enough to understand what it's about.
This also means you can read about it from better writers than I. :)
There's also a thing called 'capabilites' which is a sort of fine grained
version of setting the program suid root. Except instead of the program
'running as root' capabilites allow us to grant specific privleges like
(from /usr/src/linux/include/linux/capability.h) ...
/* Allow manipulation of system clock */
/* Allow irix_stime on mips */
/* Allow setting the real-time clock */
#define CAP_SYS_TIME 25
... so a binary with CAP_SYS_TIME set would allow you to set the system
clock (which as a user you couldn't normally) but not do any of the other
things root can do. Useful if there should turn out to be a bug in our suid
program that might allow a user to get it to do things other than what it
was intended to do. You can read about them at...
ftp://ftp.guardian.no/pub/free/linux/capabilities/capfaq.txt
... but their we'll beyond what you were asking. :)
I think the point I was tring to make is - it's complicated. There are
countless ways to skin this cat, and the only way to learn then is read, and
try and read and try and read and try and read and try. *sigh* I hope some
of that made sence and didn't just frustate you more...
M.
--
WebCentral Pty Ltd Australia's #1 Internet Web Hosting Company
Level 1, 96 Lytton Road. Network Operations - Systems Engineer
PO Box 4169, East Brisbane. phone: +61 7 3249 2557
Queensland, Australia. pgp key id: 0x900E515F
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
