🚀 go-pugleaf

bob wrote:

> Number 2 is dangerous and silly IMNSHO for the reasons I lay out below.

  As far as I can see, you don't explain why it is dangerous -- which
I interpret as increasing the risk for damage. 

> I would appreciate any critique of my reasoning, so that I can make a
> stronger argument, or avoid embarassing myself if I've missed anything.

  You may want to inquire into the exact formulation of the problem
this particular policy is supposed to lessen. After all, the policy is
a solution to a more or less well formulated problem.  But it's rather
usless to discuss a solution, unless we know exactly what the problem
is perceived to be.

  And who are you going to convince?  The people who made the policy?
Or someone who will ratify the policy? Rather different approaches will
be required ...
 
> A) No unix/linux/bsd sysadmin in the history of the world has ever
> followed or will ever follow this policy (correct me if I'm wrong).

  Is that a particularly good argument? You will surely be expected
to prove your point well enough --  at least show that you have
comprehensive information on the practices of every unix/linux/bsd
sysadmin during the period you indicate. 

 Unless you argue the point, this is just contradiction. If you
can argue the point, the flat contradiction won't be needed.

  A possible way forward is to explain why they won't do this,
or why doing so will increase costs or decrease efficiency.

> B) It is not needed to ensure commmand security, if a file integrity
> checker is run on all files in root's $PATH  (files in /etc and subdirs
> thereof should probably be included).

  This, again, depends on what the real problem is. If it involves 
user-land software that somehow can overwrite the PATH information
in a root shell, a file checker will not obviosuly be of any use.

> C) It is not sufficient to ensure command security if a file integrity
> checker is NOT run on all files in root's $PATH

  You might want to put the second half of this statement first, in order
to make it easier to parse and understand: 'if a file checker is not ...
it isn't sufficient ...'

  However, this is not argument against using full command paths:
it seems to be part of an argument involving file checkers: that
one is needed anyway?

> D) One can observe the letter of this law by simply issuing 'which
> <command>' then issuing whatever is returned, without having increased
> security one iota.  In fact, it could be issued as `which <command>` to
> save time.  (Oh all right, `/usr/bin/which <command>`).

  And why is that a problem? 

  It is also possible to follow the policy by adding command aliases
to the root shell startup file. That may be OK -- as the problem is
not defined, it's impossible to say if it involves that startup file,
or not.

  --

  From your description, it sounds as if someone believes the black-hats
can change root's PATH at will, and that there's no way to detect it
when it happens, but that the same black-hats can't change the contents
of /bin etc. without being detected. 

  --

  Just some random thoughts:

  If you're going to argue against a policy, you will almost certainly
be expected to propose an alternative solution for the problem
in question, and argue why that is better. You seem to have something
with file checkers in mind, but I think you need to present it
more clearly.
  
  One possible way to argue against it might be the question of
security cost: what is the expected efficiency of this measure?
That is, what is the relation between the cost of following this
policy and the expected reduction in damage that will be the consequence
of  following it?  It's unfortunately difficult, as assigning costs
to damages and work practices, and estimating damage probabilities
is not standard practice for UNIX sysadmins, as far as I am aware.

-- 
Anders Thulin     Anders.X.Thulin@telia.se     040-10 50 63
Telia ProSoft AB, Box 85, SE-201 20 Malm�, Sweden