🚀 go-pugleaf

Anders,

Thanx for your useful response.  My comments below.

Anders Thulin wrote:
> 
> 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.

The point I intended (but failed) to make was that this policy, in the
absence of file integrity checking (which is the current situation)
might lend a false sense of security, whereas file integrity checking is
by far the more important item.

 
> > 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.

The policy states: "These requirements prevent unwanted programs, such
as milicious scripts, being acceidentally executed without the root
user's knowledge."

> 
>   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 ...

Both.  The policy has already been ratified, sad to say.

> 
> > 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.

I cannot prove a negative, so I may have to rephrase or liminate the
argument.  I still believe that no sysadmin will do this, htoug - I've
tried, and invariably go back to the sane way of doing things.

I therefore issue the following challenge: "anyone who has ever at any
time heard of any sysadmin following this procedure, please speak up
now."

> 
> > 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.

I'm not sure how this could occur unless the program was executed as '.
<program>' which is very atypical.  Without this, (or exec) I think the
shell enivronment isn't modifiable by a program, since a copy of the
shell is forked to rrun the program and dies when the program is done.

> 
> > 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?

It goes back to the policy being neither necessary nor sufficient to
accomplish what it says it's trying to accomplish.


> 
> > 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?

The policy was followed to the letter, yet the end result was identical
to that which would have happened without the policy (the system
searched the PATH and executed the first match).  Once again, the ploicy
does not accompish what it claims to.  In fact, the policy  does nothing
other than make the sysadmin's life more difficult and provide a wholly
false sense of security.

> 
>   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.
> 

And of course, the PATH is established in profiles whcih only root can
edit.  If the blackhat can change that he already has root and can do
whatever he wants, and does need to fool me into doing it for him.


>   --
> 
>   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.

1) the root user's profile print's the PATH as the last thing it does
during login.

2) File integrity checking software is installed and configured ot check
all directories in root's PATH, as well as `find /etc/ -print`


> 
>   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


Thanx again.  Your input has been very useful.

- Bob