Matthew Melvin wrote:
> On Mon, 26 Feb 2001 at 5:30am (-0500), Jerry Human wrote:
>
> > Hello Everyone:
> >
<snip>
> > 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
>
Thank you, Mr. Matthew Melvin! That is an excellent well written example (I've
left it in this reply for others that may have missed the original, it's worth
the extra bandwidth). I actually understood every word even though I hadn't
heard of pam yet (more manpages to read) and I followed the concept every step
of the way. :-)) Very helpful. Your reply is probably the first thing I've read
in the Linux world that seemed like it was written for people instead of
computers.
After reading your reply I immediately printed it to include it in my "Linux
solutions" folder. I print a lot of emails and categorize them according to
subject (good thing I have a four drawer file cabinet!) for reference. Lurking
on the list has given me many emails (I usually get from 70 to 160 emails per
day) about various scenarios but yours is the best!
I wrote the original question just before my regular bed time (6:00 a.m.) and
went to bed. When I got up, I checked email and re-read my own submission (I do
that to see how 'dumb' I look to you guys) and while I was reading it, I thought
I could just set up a cron job as root. Low and behold, Anthony E. Greene
addressed that very subject a few emails later. Thank you Mr. Anthony E. Greene!
I am about to setup a network linking my Linux boxes and Windows box and the
basic concepts learned here will serve me well in that endeavor.
Thank you very very much.
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
