Re: Root privilege (SOLVED)
On Fri, Jan 12, 2007 at 08:51:58AM EST, Douglas Tutty wrote:
> On Fri, Jan 12, 2007 at 01:42:44AM -0500, cga2000 wrote:
Looks like our encodings do not play well with each other - see all the
question marks below.
> > This is what root's recently been up to on my laptop:
> >
> > ? manually adjusting the system & hardware clock
> Look at chrony. If you don't want it to sync to an NTP server over the
> net, it still has the capablility to take your watch time and slew the
> system time. The chrony password is _not_ the root password.
> > ? bouncing the network
> ?
/etc/init.d/networking stop|start|restart
<snip>
> > ? running a password cracker
> Make it a cron job
> > ? running chkrootkit
> Cron.
contortions ..
> > ? viewing logs
> Add yourself to group adm
more contortions ..
first of all you have to remember that:
# usermod -G adm myuser
.. wipes out all your other groups .. so you have to try and figure out
what groups you were in (or restore from a backup) .. and then issue a:
# usermod -G adm,grp1,grp2,grp3 myuser
.. don't leave out the commas between the groups..!
then every time you want to actually view the logs you have to issue a:
$ newgrp adm
But that's not all:
There are still half a dozen logs that are not associated with the adm
group but rather with the root group. So you may still have to su to
root to browse these.
Now not only is this rather annoying especially in times of stress .. I
usually browse logs when something is not working .. but I also have
this feeling that when something is so convoluted .. poorly documented
.. and obviously not designed with the user/admin in mind .. nobody
uses it and it's probably much safer to stay away from it.
Now let's imagine for a minute that there was some kind of database
where I could specify that "myuser" has - eg. read-only access to
/var/log/* and more restrictively no-access to /var/log/topsecret.log if
necessary .. instead of these peculiar "ugo" permissions attached to the
file itself (!) achieving the above would only require that the security
administrator issue a straightforward command to authorize my id to
access the logs. And better yet, there might exist a number of
"profiles" that give different types of users access (ro, rw.. etc.) to
the resources they need to perform their duties .. so all he would have
to do is issue one single command "connect" me to the relevant profile.
Done. Naturally _I_ would not need to issue any command myself such as
newgrp every time I need to access a particular resources.
Clearly this is not going to happen any time soon in the *nix world ..
so I guess I'll stick with root for the time being.
> > ? accessing /var/spool/
> routinely???
> > ? shutting down the system
> /etc/inittab --> shutdown -a...
> add yourself (and your wife?) to /etc/shutdown.allow
I thought that was something to limit the use of CTRL+ALT+DEL to
certain users only?
> > ? starting a vmware image
> > ? starting my chroot etch install
> > ? moving stuff to a fat file system
> > ? looking for and deleting core files
> So disallow core files.
I'm always curious so I usually do a:
$ file core.file
before deleting it.
> > ? teaching myself the intricacies of cron
> > ? loading/unloading modules
> Hopefully a rare event.
Not necessarily. Take the case of someone who's hacking a module because
he has specific needs not covered by the standard version.. He may need
to reload the module a few times before he gets it to work. I would
assume that on a multiuser box sudo would come in handy to limit our
hacker to modprobe and rmmod rather than give him root access to the
entire system?
More prosaically, I was only trying to get dri to work on this laptop.
> > ? adding/removing software with apt
> > ? kernel upgrades/reconfiguration (partially as root)
> > ? make-installing software compiled from source
> > ? running dpkg-reconfigure
> > ? manually running updatedb
> > ? sync'ing file systems
> > ? renicing tasks
> > ? changing file ownership/permissions
> > ? adding an entry to the terminfo database
> > ? running lilo
> > ? mounting/unmounting file systems
> If this is routine and a user should be able to do it, look at the user
> option in /etc/fstab. I think you can limit this ability to a
> particular user (or group?)
> > ? running backups
> > ? creating/burning iso images
> You can setup xcdroast to give this ability to individual users.
I use cdrecord.
But the problem is that my burner is defined like so:
crw------- 1 root root 21, 0 2002-08-29 18:00:48.-0400 /dev/sg0
So only root has access to it. Mind you I could chown it over to my
user .. or change the group to cdrom and give it group rw permissions.
The trouble about this approach that all these little changes add up and
I tend to forget these things. Some way or other I suspect this'd come
back and bite me when I least expect it. And then with this strategy
I'd still have to newgrp to the cdrom group before I could do anything,
right..?
> > ? system tools such as fdisk that may require root privileges
> I save the partition table as part of my backup script (also run as
> root).
Sounds like a very good idea to me.
> > ? same for the network -- ifconfig .. ip .. tcpdump ..
> > ? editing config files in the directory tree
> > ? killing misbehaving processes
> > ? changing root's password
> > ? testing the OP's problem
> >
> > Notes:
>
> > 2. A significant number of tasks do not require root privileges .. some
> > simple stuff such as adding /sbin to my $PATH .. adding myself to a
> > couple of groups .. etc. would let me perform these at least in part
> > under my regular account.
>
> I've heard some people suggest that root should have no path so a full
> path has to be used to run a command. Not having /sbin in your $PATH
> doesn't keep you from running a command in /sbin.
Yes. Even if you're not root there are circumstances where it's
preferable to get into the habit of specifying the full path to
guarantee you are not picking up garbage from some place else:
$ /bin/su -
.. rather than
$ su -
.. for instance.
> > But then I'd have to think .. does this particular option or feature
> > require root privileges .. ?? I don't want to have to think about
> > such aspects. I mean, I'm looking for clues in /var/log .. some logs
> > are world-readable and others are not.. The problem I'm dealing with
> > may be quite serious.. I am already in a foul mood .. Do I really
> > need the additional aggravation of having to switch accounts while
> > investigating..?
> In pam.d/su make adm the wheel group. Put yourself in group adm. If
> you really trust your password then set it up so you don't need the root
> password. Then to do something as root its just su - ...
Interesting. But I'd rather enter the root password a few times a day
to make sure I don't forget it.
:-)
> Don't do root stuff when you're in a foul mood...
Since I'm always in a foul mood, this might be a good reason to stop
using root.
Thanks much for your comments.
cga
Reply to: