Re: Restricted Shells or Menu Based Shells

From: Derek D. Martin (ddm@mclinux.com)
Date: 02/26/02


Date: Tue, 26 Feb 2002 13:37:11 -0500
From: "Derek D. Martin" <ddm@mclinux.com>
To: focus-linux@securityfocus.com

Seth Arnold said:

> Note that your life may be significantly easier if you put all untrusted
> users in one group, trusted users in another group, and fiddle with
> group and world execute permissions on all the executables on your
> system. The executables anyone can run (e.g., pine) can be made world
> executable. The executables only trusted users can run can be made owned
> by their group, and group executable.

This can be an effective strategy, but the way you describe it is
actually a little more complex than it needs to be. You do not
actually need to have a trusted group; you only need an untrusted
group. The key here is the often overlooked fact that groups can be
used to TAKE AWAY privileges as easily as they can be used to grant
access. This is because of the way Unix permissions work.

If you are the owner of a file, when permissions are checked, the
kernel will look at the owner permissions only, and make access
decisions based on those. If you are not the owner, it will next look
to see if the group of the file is one you belong to (exactly which
groups it checks, e.g. primary and/or auxilliary, is somewhat
dependent upon implementation). If you do belong to the group that
owns the file, the kernel will look at the permissions for the group
AND STOP THERE, and make access decisions based on those permissions,
REGARDLESS OF LESS RESTRICTIVE PERMISSIONS FOR "OTHER."

So, for example, if you had a group "untrusted" that you didn't want
to access a particular executable, say, /bin/false, you'd set the
permissions like this:

  -r-x---r-x 1 root untrusted 4436 Jan 16 2001 /bin/false

Anyone in the untrusted group can now no longer run /bin/false.
Everyone else, not being a member of the untrusted group, can run it
as they please.

-- 
Derek Martin
Senior System Administrator
Mission Critical Linux
martin@MissionCriticalLinux.com



Relevant Pages

  • Re: Environment.CommandLine Security Exception
    ... > and look at the Intranet/Internet permissions chart: ... running into is executables ... this would be the Local Intranet zone. ... >> condition in a code group, ...
    (microsoft.public.dotnet.security)
  • Re: Environment.CommandLine Security Exception
    ... so that you allow exactly and only the permissions you wish the code to ... > running into is executables ... this would be the Local Intranet zone. ... >>> condition in a code group, ...
    (microsoft.public.dotnet.security)
  • Re: Environment.CommandLine Security Exception
    ... What you are running into is executables ... from a share run under the Local Intranet zone, with diminished permissions. ... signing and creating a custom code group are not ...
    (microsoft.public.dotnet.security)
  • Re: Environment.CommandLine Security Exception
    ... But isn't CASPOL and the .Net Framework Configuration ... the appropriate permissions, the program should run ... >both assemblies FullTrust, or, ... >>> running into is executables ...
    (microsoft.public.dotnet.security)
  • Re: Environment.CommandLine Security Exception
    ... What you are running into is executables ... > from a share run under the Local Intranet zone, with diminished permissions. ... > condition in a code group, using either the .NET Configuration Tool ...
    (microsoft.public.dotnet.security)