Re: Granting root access?

From: Juhan Leemet (juhan_at_logicognosis.com)
Date: 07/30/04 

Date: Thu, 29 Jul 2004 22:47:42 -0200

On Thu, 29 Jul 2004 16:28:29 +0000, Larry I Smith wrote:
> Arthur Hagen wrote:
>> Larry I Smith <larryXiXsmith@verizon.net> wrote:
>>>Arthur Hagen wrote:
>>>>Larry I Smith <larryXiXsmith@verizon.net> wrote:
>>>>
>>>>>In general, 'root' installs and maintains, everyone
>>>>>else just uses the system.
>>>>
>>>>In most cases, it's overkill to have root installing...
>>>
>>>Sorry, 15+ years working with unix in a large corporate environment...
>>> 'root' installs and maintains, everyone else just uses the system...
>>>
>>>NO ONE (nobody, not ever, nada) makes any changes to the box outside of
>>>their home dir without approval from the 'root' admin.

Ah, but a "test install" could be in a user's home directory, or in an
approved test area. It should be appropriately protected and limited. One
could argue/discuss who should be testing/approving what programs.

>>>All other approaches risk breaking security (not to mention all of my
>>>training, and the risk of losing my job).
>>>
>>>A home linux box - same rules.

Huh? That does not make sense. If there is something you (or anyone,
for that matter) wants to try on a home Linux box, to learn something,
what better place to do it? Or are you the home computer gestapo? For whom
are you making/applying those rules? To yourself? Your family?

The other poster might have a good suggestion here. Even if it's just you,
you might want to build and/or test "foreign" applications in a restricted
area as a normal users first. Only use "root" when you really need to. As
an example, I always try to (re)build RPM packages from source using my
presonal userID. In some cases that does not work (one could argue about
badly formed .spec or installation script(s)?), then I'll examine why, and
(if I'm comfortable with it) then I'll do the build as "root". I do my
installs as "root", but first on a test machine, then across machines.

>> But there's no contradictions here. A trusted root *person* can do
>> most installs from a non-root *account*. That *increases* security --
>> especially if the account is a locked one that has to be su'd to as
>> root.

There's no such thing as a "root person". There are ordinary users (with
their personal accounts), and there are people who know the root password.
Those people are really indistinguishable if/when they log straight in as
"root", so you better trust them. The best approach is that everyone logs
in as themselves, and only does "su" to "root" if allowed/necessary.

>> To use root for this is in most cases unsafe and bad practice. I
>> usually create a "software" user and group just for this purpose.

OK, sounds a bit like a "test" user account. I might buy that.

I tend to favor the idea that the "real" software should be installed by
root. Running around tinkering with file/directory ownership and
permissions is not a particularly good idea. Too much opportunity for
error. Better to use a package manager (as "root") to (re)install.

>> To pick nits, yes, your users make changes outside their home dir all
>> the time, unless you run a chroot jail for each user (yes, I worked a
>> place I had to do this, to protect them from themselves). /tmp,
>> /var/tmp and /var/mail get modified all the time. And as an oldtimer
>> sysadmin myself, I would *prefer* it if the users did the install on a
>> dev box from a non-root account -- to their own home directory if
>> possible (if GNU autoconf-based software, like most software is these
>> days, --with-prefix=$HOME works fine, and otherwise, -rpath works
>> wonders too), before handing it to me for a system install. That way,
>> they can at least tell me useful tidbits like "it needs a newer version
>> of zlib than what's on the system", and I can check other software and
>> make a decision on whether to compile it in static, add it to an
>> app-specific directory, or upgrade the system. Unfortunately, being
>> able to compile and install something to their home directory is beyond
>> the vast majority of users. Even if they have a wall full of tech
>> certifications and 6-figure salaries.

Well, those are tiny nits. I would split those nits: if a program
(e.g. an sid program?) writes into some common system area on your behalf,
that is not the same as you going in there and doing something. Using the
"mail" application is "normal system use". Poking/tinkering in
/var/spool/mail (or whatever) is NOT "normal system use" and is suspect.

I note the "dev box" qualifier here! I tend to agree that "dev" users and
"dev" environments must be usable and modifiable/extendable. You can't
expect developers to be creative and inventive if you cripple their
creation and invention. Their facilities should include customizing
the development environment. However, "dev" users must be responsible
users within the corporate IT environment and help sysadmins keep things
running and make things better. No bickering. No passive aggression.
However, no "lording it over the users" like some BOFH, either.

I've worked places where (for example) the team lead in a system dev group
had MUCH more experience than any of the sysadmins in the place. He would
occasionally help them out. He did tune his own environment, but
responsibly, explaining to the sysadmins: where, how, why, etc.

> I see. Our users are not allowed to install anything, not even in their
> home dirs. The first offense gets one put on probation, a second
> offense gets one fired. Everyone uses only the app's approved by IT
> Security, and those apps are setup/maintained by the admins. The senior
> folks are extremely concerned about keeping "non-approved" s/w out off
> of the corporate machines.

OK, maybe, but it also suggests that your internal security setup is maybe
a bit shakey? A normal user should not be able to affect any other user or
root, if your installed software and file/directory permissions are
correct. Do you include your prohibition to scripts? So, if I were working
for you and I found (or wrote) some useful script that helps me do my job,
then you and your company policy would forbit me from using it? That
sounds like M$ shop or (some) mainframe thinking. What kind of users do
you have? Button pushers? I'm glad I don't work there. Reminds me of a
place that told me I was not allowed to buy books to learn extra stuff to
do my job better. Don't work there anymore either: I quit (over that and
other issues) and they went bankrupt (not because of me but for policies).

OTOH, I have also done consulting contracts for financial and telco
companies. They often do have "production systems" that one simply does
not screw around with. However, even there, "normal users" were allowed to
write their own scripts/JCL and figure out "better ways". Maybe that's
what you mean: "if they catch you messing with the $$$, you're toast!"

The other poster did qualify his environment machines as "dev box". 

-- 
Juhan Leemet
Logicognosis, Inc.