Re: Kill the DOG and win 100 000 DM

["Jeffrey W. Thompson" <thompson () ARGUS-SYSTEMS COM>]

HD,

What you are encountering is something known as an access authorization.  On a
PitBull Foundation (B1) system, we can place a requirement that a user must have
a specific authorization in order to execute a binary.  This information is
stored with the inode on the file system.  This take takes place during the exec
system call.  An access authorization may be set on an executable through the
chauth command
(http://www.argusrevolution.com/cgi-bin/man.cgi?section=all&topic=chauth).

More general information on authorizations can be found in the Security Features
User's Guide at:

http://www.argusrevolution.com/pitbullsupport.html in section 2.5

What you are seeing in regards to the directories is occurring because of
mandatory access controls.  Here is what is happening

When you are seeing the directory you are actually looking at the contents of its
parents directory.  Since you are passing the mandatory access control check for
read on this directory you are able to see what it contains (for example the
apache sub-directory).  However, the apache sub-directory is protected at a
different MAC level.  You are not passing this check and thus are unable to see
its contents. It is important to remember that this MAC protection is tied to
your process and not to your user id.  So even if you manage to break a setuid
program and become a new user, you will still retain your MAC level and be unable
to see the apache directory.

For more information on MAC take a look at the Security Features User's Guide
mentioned above in section 2.6 and 2.7. (In fact, I recommend browsing the whole
thing! :) )

Please let me know if you would like me to go into any more detail, or if you
have any questions after reading the SFUG.

Cheers,

Jeff

Jeff Thompson
Software Evangelist and Visionary
Argus Systems Group, Inc.





H D Moore wrote:

> Hi Jeff,
>
> I was wondering if pitbull actually marks executables as being allowed or
> not, whether by adding something to the bin_fmt (extra flag) or at the
> kernel/VFS layer.
>
> The reason is that on the test system, there are a couple executables which i
> should be able to execute, but the system won't allow.  These include
> login.back and crontab.
>
> Something else I noted that is somewhat interesting, there are quite a few
> directories which seem to exist, but attempts to list them return no such
> file/dir.  An example is /usr/local/apache, I know its there, find knows its
> there, but ls refuses to see it. Because you guys stripped the compiler,
> perl, and any other decent programming/scripting language, I couldnt dig
> deeper into exactly which syscalls are affected.
>
> -HD
>
> On Wednesday 08 November 2000 03:25 pm, you wrote:
>
> > I believe that the above addresses the questions that I saw.  I am of
> > course happy to discuss them in greater length with anyone who wants to,
> > either on the list or in private email.  Obvisouly, if anyone has other
> > questions I'll happily try to answer them.
> >
> > Cheers,
> >
> > Jeff
>
> --
> http://www.DigitalDefense.net    (work)
> http://www.DigitalOffense.net     (play)