🚀 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

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

bob <bob@none.for.me.com> writes:

>2) The root user should issue ALL commands with the full path, eg.
>'/bin/ls' instead of 'ls'

That's only a valid policy when executing from under a user's
environmetn (something policy should actually prohibit because users
have so many ways to trick you).

And it doesn't help:

alias /bin/su my-tricky-su

works fine in /bin/csh and derivatives.

Perhaps you should require full pathname and a preceding
backslash?

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

This is a multi-part message in MIME format.
--------------758876F3A56C5783A26AE0B1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

bob wrote:
> 
> 2) The root user should issue ALL commands with the full path, eg.
> '/bin/ls' instead of 'ls'
> 
It's probably easier to make sure that you have a "secure" PATH before
starting to execute commands.
At this level, you should also probably check the following before
running a command:

 - That the command is in fact owned by root
 - That the command itself and each directory in the command path is
writable only by root

And, hey - there are shells that, AFAIK, do this for you, since this is
a requirement in C2 environments. In AIX, for example, you have the
restricted shell.
--------------758876F3A56C5783A26AE0B1
Content-Type: text/x-vcard; charset=us-ascii;
 name="palm.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christer Palm
Content-Disposition: attachment;
 filename="palm.vcf"

begin:vcard 
n:Palm;Christer
tel;cell:+46 (70) 327 30 23
tel;fax:+46 (8) 23 49 01
tel;work:+46 (8) 23 49 00
x-mozilla-html:FALSE
url:http://www.nogui.se
org:NOGUI AB
adr:;;Palmfeltsv�gen 21;JOHANNESHOV;;SE-121 62;SWEDEN
version:2.1
email;internet:palm@nogui.se
title:UNIX-Specialist
note:OBS! Ny adress!!
x-mozilla-cpt:;-31296
fn:Christer Palm
end:vcard

--------------758876F3A56C5783A26AE0B1--

This is a multi-part message in MIME format.
--------------7137F92987C71A29E29469D1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oh, and I forgot to say that you also need to check LIBPATH for any
non-root writable object files, or non-root writable directories in the
paths, as well as any library paths contained within the executable.
--------------7137F92987C71A29E29469D1
Content-Type: text/x-vcard; charset=us-ascii;
 name="palm.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christer Palm
Content-Disposition: attachment;
 filename="palm.vcf"

begin:vcard 
n:Palm;Christer
tel;cell:+46 (70) 327 30 23
tel;fax:+46 (8) 23 49 01
tel;work:+46 (8) 23 49 00
x-mozilla-html:FALSE
url:http://www.nogui.se
org:NOGUI AB
adr:;;Palmfeltsv�gen 21;JOHANNESHOV;;SE-121 62;SWEDEN
version:2.1
email;internet:palm@nogui.se
title:UNIX-Specialist
note:OBS! Ny adress!!
x-mozilla-cpt:;-31296
fn:Christer Palm
end:vcard

--------------7137F92987C71A29E29469D1--

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

In article <3A8250E2.31940B6A@telia.se>,
Anders Thulin  <Anders.X.Thulin@telia.se> wrote:
>bob wrote:
>> 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. 

Anyone who has worked in a few different organizations can probably
describe common habits of sysadmins and recognize something that's
extremely unusual.  For something like this, a comprehensive survey is
hardly necessary.

-- 
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

bob wrote:
> >> 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).
> >

Then Anders Thulin  <Anders.X.Thulin@telia.se> wrote:
> >  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.


Then Barry Margolin wrote:
> 
> 
> Anyone who has worked in a few different organizations can probably
> describe common habits of sysadmins and recognize something that's
> extremely unusual.  For something like this, a comprehensive survey is
> hardly necessary.

So, Barry, have you ever seen a sysadmin issue all commands with full
paths?  Unfortunately, I've only worked one place since I started using
Unix.  I've never seen it or heard of it.

Any help is much appreciated.

Barry Margolin wrote:

> Anyone who has worked in a few different organizations can probably
> describe common habits of sysadmins and recognize something that's
> extremely unusual.  For something like this, a comprehensive survey is
> hardly necessary.

  I agree -- but it's not the sysadms who need to be convinced in this
case. It's the people who decided that this protection mechanism was
required, as well as the people who made it into a rule. Will your
argument convince them? It may, if they trust their sysadms.

  But probably not. Then it becomes a procedural question: what does
it take to change a security rule?  (A good security policy should state
that mechanism...)

  Refusal to follow the rule may be taken as an indication of a problem
by a reasonably enlightened management.  If that is a likely path forward,
it might make sense to wait until the first verification is made that the
rules and policies are implemented.

  --

  Further ruminations:

  It seems that the rule is a 'last line of defense' kind of rule. I
don't believe it's wise to place the implementation of such rules
entirely in the hands of users, without any support.

  Is there any shell that is capable of protecting PATH from malicious or
accidental modification? If there is, using it might be a better
solution to the problem. 

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

In article <3A837DE5.BA4726B4@none.for.me.com>,
bob  <bob@none.for.me.com> wrote:
>So, Barry, have you ever seen a sysadmin issue all commands with full
>paths?  Unfortunately, I've only worked one place since I started using
>Unix.  I've never seen it or heard of it.

No, I've never heard of a sysadmin doing this.  I've worked in two
Unix-based organizations, and been to LISA conferences and attended
security seminars, and never seen anyone suggest it before.  I thought I
implied all this when I referred to it as "extremely unusual".

-- 
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

In article <3A83AA16.91A4731F@telia.se>,
Anders Thulin  <Anders.X.Thulin@telia.se> wrote:
>  Refusal to follow the rule may be taken as an indication of a problem
>by a reasonably enlightened management.

I think referring to disobeying this policy as "refusal" is inappropriate.
That suggests active defiance of the rule.  It's more likely that they'll
simply forget, since it's different from the normal way they learned to use
Unix.

I would only call it "refusal" if the site configures root's shell with an
empty PATH, and the sysadmin manually changes the PATH to get around the
policy.  But as long as typing commands without full paths works, they're
unlikely to change their ingrained habits.

-- 
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

In article <GzWg6.21$4w6.5444@burlma1-snr2>,
Barry Margolin <barmar@genuity.net> writes:
|> In article <3A837DE5.BA4726B4@none.for.me.com>,
|> bob  <bob@none.for.me.com> wrote:
|> >So, Barry, have you ever seen a sysadmin issue all commands with full
|> >paths?  Unfortunately, I've only worked one place since I started using
|> >Unix.  I've never seen it or heard of it.
|> 
|> No, I've never heard of a sysadmin doing this.  I've worked in two
|> Unix-based organizations, and been to LISA conferences and attended
|> security seminars, and never seen anyone suggest it before.  I thought I
|> implied all this when I referred to it as "extremely unusual".

I have seen it suggested.  I have even seen it tried.  It didn't
take long for reality to intrude.  Usually minutes or hours, but
occasionally a little longer.

In fact, the whole idea is more impractical than it might appear,
as there are a significant number of scripts and programs that are
shipped as part of an otherwise respectable vendors' system (and,
yes, I do mean ones like /usr/sbin/munge_network) that will not
work unless PATH is set up in the way they expect.

I have even seen scripts and programs that require to be supplied
command names in the short form, and the full path name will not
do.  I felt very ill on the discovery.


The SENSIBLE thing, of course, is to learn from the experience of
1960s and 1970s systems, and have proper environmental defaults
and constraints both per-user and per-program.  Such as a
configuration file that lists directories that are permitted to
be in root's path; any attempt to include others would be logged
and suppressed.  And the ability to bind an environment to a
program, so that it could not be confused by the caller.

A few Unices have a few of these features, but regrettably few,
and even fewer have a properly designed environment control scheme.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

Christer Palm wrote:
> 
> It's probably easier to make sure that you have a "secure" PATH before
> starting to execute commands.
> At this level, you should also probably check the following before
> running a command:
> 
>  - That the command is in fact owned by root
>  - That the command itself and each directory in the command path is
> writable only by root
> 

Well, I wrote a nice little perl script to do this, thinking the script
would be simple (which it was, actually), with the following results
(which aren't simple):

Many commands on both linux and solaris are owned by other than root,
users such as news, uucp, bin to name a few.  And on solaris many are
writable by group, groups being similar to the preceding.

I suspect that these users cannot login (second field in /etc/shadow
entry is '*') but I'm not sure of this.  So is this safe or what?  Where
do I go from here?


> And, hey - there are shells that, AFAIK, do this for you, since this is
> a requirement in C2 environments. In AIX, for example, you have the
> restricted shell.

Know of any likje this for linux or solaris?

Thanx for the help.

- Bob

In article <3A837DE5.BA4726B4@none.for.me.com>,
bob  <bob@none.for.me.com> wrote:
>
>So, Barry, have you ever seen a sysadmin issue all commands with full
>paths?  Unfortunately, I've only worked one place since I started using
>Unix.  I've never seen it or heard of it.


No, he hasn't.  (I'm going out on a limb here, but what the heck) :^)

The only reason to not allow ./foo, and instead require /some/path/to/foo,
is to make sure that root doesn't run the wrong "foo" because (s)he forgot
what her cwd was.  That is a laudable goal, but the means by which they are
attempting to achieve it are too burdensome to make it worthwhile.

You'd be better off cooking up some hack that that prints the current 
directory as part of root's shell prompt.  I do not mean to restart the
"Changing root's shell considered harmful" thread ;^)

Chris

bob wrote:
> Know of any likje this for linux or solaris?
> 
> Thanx for the help.
> 
> - Bob

  You can get a C2 version of Solaris. You pay rather more for it.

  With Linux it is rather difficult, since certification doesn't have a
lot of meaning when any user can change any tool included in any
distribution. Therefore I do not think we will see any C2 (or any other
colourful-book) certified Linux. I believe there is an effort ongoing at
NSA to do _something_, but You'd be well advised to examine the sources
_vary_ closely between download and compile.

  You can get even B-class unixen, if You're willing to pay. They exist,
though not in the regular pricebooks... Well, maybe except for SCO.

This is a multi-part message in MIME format.
--------------CC8C72541612CE7C469E2956
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

bob wrote:
> 
> Well, I wrote a nice little perl script to do this, thinking the script
> would be simple (which it was, actually), with the following results
> (which aren't simple):
> 
> Many commands on both linux and solaris are owned by other than root,
> users such as news, uucp, bin to name a few.  And on solaris many are
> writable by group, groups being similar to the preceding.
> 
> I suspect that these users cannot login (second field in /etc/shadow
> entry is '*') but I'm not sure of this.  So is this safe or what?  Where
> do I go from here?
> 
Right - more specifically the executable and the directories in its path
should only be writable by "trusted" users and groups. This also goes
for any shared libraries referenced by the executable. A user that
cannot log in can be considered trusted, as well as groups in which only
root or trusted users are members. You should be able to put this check
into your perl program as well fairly easily.

It would be nice to be able to have the kernel check this for you in
exec()...
--------------CC8C72541612CE7C469E2956
Content-Type: text/x-vcard; charset=us-ascii;
 name="palm.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christer Palm
Content-Disposition: attachment;
 filename="palm.vcf"

begin:vcard 
n:Palm;Christer
tel;cell:+46 (70) 327 30 23
tel;fax:+46 (8) 23 49 01
tel;work:+46 (8) 23 49 00
x-mozilla-html:FALSE
url:http://www.nogui.se
org:NOGUI AB
adr:;;Palmfeltsv�gen 21;JOHANNESHOV;;SE-121 62;SWEDEN
version:2.1
email;internet:palm@nogui.se
title:UNIX-Specialist
x-mozilla-cpt:;-21600
fn:Christer Palm
end:vcard

--------------CC8C72541612CE7C469E2956--

Christer Palm wrote:
> 
> bob wrote:
> >
> > Well, I wrote a nice little perl script to do this, thinking the script
> > would be simple (which it was, actually), with the following results
> > (which aren't simple):
> >
> > Many commands on both linux and solaris are owned by other than root,
> > users such as news, uucp, bin to name a few.  And on solaris many are
> > writable by group, groups being similar to the preceding.
> >
> > I suspect that these users cannot login (second field in /etc/shadow
> > entry is '*') but I'm not sure of this.  So is this safe or what?  Where
> > do I go from here?
> >
> Right - more specifically the executable and the directories in its path
> should only be writable by "trusted" users and groups. This also goes
> for any shared libraries referenced by the executable. A user that
> cannot log in can be considered trusted, as well as groups in which only
> root or trusted users are members. 

This is more or less what I thought - check /etc/shadow for users tahat
can't login and consider them trusted.  Still haven't worked out the
libraries yet, though.

> You should be able to put this check
> into your perl program as well fairly easily.
> 
> It would be nice to be able to have the kernel check this for you in
> exec()...

In comp.security.unix bob <bob@none.for.me.com> wrote:
>> Right - more specifically the executable and the directories in its path
>> should only be writable by "trusted" users and groups. This also goes
>> for any shared libraries referenced by the executable. A user that
>> cannot log in can be considered trusted, as well as groups in which only
>> root or trusted users are members. 

> This is more or less what I thought - check /etc/shadow for users tahat
> can't login and consider them trusted.  Still haven't worked out the
> libraries yet, though.

And be aware that in case of NFS Export of that dir every remote host can
impersonate those users. Thats why you better make all those files owned by
root.root and use root_squash. This will at least avoid modifications that
way. (or use /usr and / mounted read only in addition.

Greetings
Bernd