Today, Bob Bell gleaned this insight:
> On Tue, Jun 20, 2000 at 09:04:46PM -0400, Derek Martin
><[EMAIL PROTECTED]> wrote:
> > Today, Bob Bell gleaned this insight:
> > root access, yes. root password, no. Actually as Paul pointed out, sudo
> > can be used to provide any granularity of root access that is desired. We
> > regularly use it ourselves, despite actually having the root password.
> > This, at least, provides some accounting of what was done.
>
> sudo is not always available...
Sure it is... It's freely available and compiles on virtually any U*IX.
it's up to the system administrators to make it available if it isn't
there. And if you're one of the people developing the OS you're trying to
sell, you should get your people to make sure it ships with the OS! It's
an invaluable administration tool.
>
> > However, I would maintain that in a well-designed environment, you would
> > not be doing OS development on your "regular" desktop workstation... you
> > would have a lab workstation which does not do things like:
> >
> > * Mount NFS directories
> > * participate in NIS
> > * have any other sort of network trust relationships.
>
> Yes, I normally work on designated workstations, although I do
> muck with my own machine from time to time (we like to try to sleep in the
> bed that we've made). However, in my environment I do more than just
> test kernels. I may actually need to check NFS directories, try
> different NIS setups, etc. Having an entire test network set up could
> get quite expensive.
You have a point about the cost, but I assume there are more developers
than just you? Typically what I have seen is a small lab network set up
for all the engineers to test such things on... but it depends on where
you work and what you're doing. I would expect that if you were working
for, say, DEC, it would be fairly painless for them to provide a small
test network for such a group. You can use a relatively small number of
inexpensive machines for such a setup... For example you could provide one
or two low-end alphastations that each run NFS, NIS, DNS, and/or whatever
else you need.
If that weren't sufficient, I would expect that they would have at least
one of each of their larger machines available for a given group, or
perhaps a group of groups, to use for testing. Until you get to the
highest of high-end, the cost just isn't that prohibitive for a hardware
vendor to provide its engineers machines to test and develop on, unless
they're just not selling ANY product. (Oh wait, we're talking about DEC
here... they never did sell any alphas, did they? :) In fact it doesn't
make any sense to me that such machines WOULDN'T be available to the
engineers. How else could they be sure their stuff worked?
> I also never quite know what I am going to need to do next. This
> makes it hard to just grant certain priveleges. It would be a *huge*
> damper on productivity if I had to ask for permission each time I
> needed to try something different as root. And what would be the
> point of using sudo to grant full access to everything?
The point is at least there's some accountability. sudo logs everything
you do when you run it. I would prevent my users from being able to run
any of the shells and editors that provide a shell, and make it clear that
if you run a program that gives you generic root priveleges, you're
violating the security policy and there will be consequences. Then have
any such system log to a remote syslog server and have a log parser watch
for violations. NOTE: THIS IS ONLY NECESSARY FOR MACHINES WITH TRUST
RELATIONSHIPS WITH PRODUCTION MACHINES. If you want to completely
disassociate a given machine from the network, i.e. don't get NFS mounts
and be disallowed from participating NIS (actually NIS is a whole seperate
security fiasco, but that's a topic for another day), then none of this is
necessary.
The point of all this is that the sysadmin team is responsible for
security. They have to have some tools available to them to make things
secure, but you have to trust your users at least a little bit. So beyond
that you need tools to audit security and provide the admin team with a
picture of what's going on if someone is doing something naughty.
A single workstation with a trust relationship, whose root password has
been given out to an engineer is a giant gaping security hole, no matter
how you slice it. Got root on one machine? You can probably get it on
another if it has any kind of trust relationship. Doesn't matter what
flavor of U*IX you're talking about... Now multiply that scenario by 100
engineers or 1000 engineers, and you have a nightmare. You may as well
not even bother about security, and just be prepared to be sued because
your employees are breaking into other networks, lose hardware and data
because a disgruntled engineer had a bad day, and have your products
stolen via industrial espionage. Cuz that's exactly what's going to
happen, as history has more than adequately demonstrated.
Most people are nice, but it's the 10% or so who aren't that ruin it for
the rest.
> Umm, I often can't boot past single user mode. Yes, I can hose my
> machine that much. In fact, recently I've been doing it
> intentionally, as I've been working on a cluster recovery script. I
> need to be able to reinstall the OS from CD. I'm going to grab some
> administrator and get him to type something in when it asks for the
> root password? Ridiculous!
Basically covered this one already. Yes it would be ridiculous. For a
machine with such a purpose, you get the root password, but no network
resources other than a port punched down (and even that makes me paranoid
for the above mentioned reasons).
Basically, you get a choice: root password, or network resources. You
can't have both, because you've compromised my network if you do.
As evidenced by the fact that there are shops doing it today, it *CAN* be
done... as I said before, you just need to change the way you think and
work. Engineers resist it because it's less convenient, and it IS less
convenient, but it's far from impossible. And from the company's
standpoint, the cost is too high NOT to do it.
--
PGP/GPG Public key at http://cerberus.ne.mediaone.net/~derek/pubkey.txt
------------------------------------------------------
Derek D. Martin | Unix/Linux Geek
[EMAIL PROTECTED] | [EMAIL PROTECTED]
------------------------------------------------------
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
