Thanks for the long post. I'll check out those url's you listed for the ACL
extensions.
You are close to what it is that we are trying to run here. I'm not that
good at putting this
into ascii art but to give a /unix/ style breakdown as to what we have.
Groups:
CLIENT1
CLIENT2
VENDOR1
VENDOR2
VENDOR3
SUPPORT1
SUPPORT2
users:
client10
client20
vendor10
vendor20
vendor30
support10
support20
daemon
the user 'daemon' is a part of all groups to have access to all directories.
The user is not root (for OS security issues).
the directory map can be displayed like this:
dr-xr-xr-x 7 root other 512 Nov 3 1999 CLIENT1
drwxr-xr-x 27 root other 512 Aug 8 14:48 CLIENT1/pub
drwxr-x--- 6 root VENDOR1 512 Jul 31 17:15 CLIENT1/pub/VENDOR1
drwxrwx--- 2 root VENDOR1 512 Jul 12 15:05 CLIENT1/pub/VENDOR1/from_US
drwxrwx--- 2 root SUPPORT1 512 Jul 10 15:19 CLIENT1/pub/VENDOR1/to_VENDOR1
drwxrwx--- 2 root VENDOR1 512 Jul 12 14:19 CLIENT1/pub/VENDOR1/to_US
drwxrwx--- 2 root SUPPORT1 512 Jul 12 15:05 CLIENT1/pub/VENDOR1/from_VENDOR1
drwxr-x--- 6 root VENDOR2 512 Jul 31 17:15 CLIENT1/pub/VENDOR2
drwxrwx--- 2 root VENDOR2 512 Jul 21 16:49 CLIENT1/pub/VENDOR2/from_US
drwxrwx--- 2 root SUPPORT1 512 Jul 21 16:49 CLIENT1/pub/VENDOR2/to_VENDOR2
drwxrwx--- 2 root VENDOR2 512 Jul 24 10:58 CLIENT1/pub/VENDOR2/to_US
drwxrwx--- 2 root SUPPORT1 512 Jul 24 10:58 CLIENT1/pub/VENDOR2/from_VENDOR2
drwxr-x--- 6 root VENDOR3 512 Jul 31 17:14 CLIENT1/pub/VENDOR3
drwxrwx--- 2 root VENDOR3 512 Jul 31 16:42 CLIENT1/pub/VENDOR3/from_US
drwxrwx--- 2 root VENDOR3 512 Jul 31 17:24 CLIENT1/pub/VENDOR3/to_US
drwxrwx--- 2 root SUPPORT1 512 Jul 14 15:10 CLIENT1/pub/VENDOR3/to_VENDOR3
drwxrwx--- 2 root SUPPORT1 512 Apr 20 16:41 CLIENT1/pub/VENDOR3/from_VENDOR3
d--x--x--x 2 root other 512 Apr 8 1998 CLIENT1/bin
d--x--x--x 2 root other 512 Apr 2 1998 CLIENT1/dev
d--x--x--x 2 root other 512 Apr 2 1998 CLIENT1/etc
d--x--x--x 3 root other 512 Apr 2 1998 CLIENT1/usr
d--x--x--x 2 root other 512 Apr 2 1998 CLIENT1/usr/lib
Each client has it's own chrooted environment. we have say three vendors
(VENDORS[1-3]) dropping
off files. Each vendor has access only to their own sub-directory under the
client's environment. Each
client has 1-2 people who have access to all of their vendor's directories
(groups), but no access to
any of the SUPPORT groups (which are OUR users). Likewise, we have a team
per client. That team
is assigned a support group. That group [SUPPORT1] has access to only their
directories not the vendor's
directories. There is generally 1 person (team leader) who has access to
BOTH vendor groups and support
groups for that client.
In addition there is the daemon user who has access to all vendor & support
groups as all scripts/programs
are run from this account.
Some vendors may support more than one client in which case they have
different user id's. (vendor10, vendor11
et al). each one is set up the same way but limited to that specific
client). each client is chrooted so there is
no way cross that boundary besides logging into it with a different userid
and being directed.
Now this is a small example. This scales to that per client there may be
say 16-60 vendors, and several clients
(50+).
Security is high and you are correct compartmentalized. ACL's would help
though there is a maintence issue.
Generally second level techs maintain this and third level set up the
environment. (ie, 3rd level builds the box/system
and then turns it over to second to handle the day-day adding/creating
accounts for clients). A kernel change
would be relatively easy to put into place once and then no additional
training really needs to take place at
the second level admin area.
I hope I haven't confused the issue too much you were very close with your
diagram.
Steve
----- Original Message -----
From: "Jesse Pollard" <pollard@tomcat.admin.navo.hpc.mil>
To: <lists@chaven.com>; "Jesse Pollard" <pollard@tomcat.admin.navo.hpc.mil>;
<matthew@wil.cx>
Cc: <linux-kernel@vger.rutgers.edu>
Sent: Tuesday, August 08, 2000 08:48
Subject: Re: 2.2.* kernels w/ glibc-2.1.* allowing ngroups_max to be > 128?
> "List User" <lists@chaven.com>:
> > Our situation here is that we have several groups based on clients.
Each
> > client is a group and has several users in that group. Likewise we have
an
> > internal support group for each client which also consists of several
users.
> > In addition to this we have certain processes (PGP, and others) that
need to
> > cross both groups to move data & encrypt it. No one in any group should
> > have ownership authority for the directories. Only user associated to
the
> > 'system' tasks (like PGP) should have access to all groups. Internal
users
> > should have access to their own group files as well as files to only the
> > clients that they support.
> >
> > The problem rises when some clients have sub-vendors that need to be
part of
> > that client's group but are not allowed to
> > see any other sub-vendor's data. But all internal and the client can
see
> > that data. It's a convoluted system to really describe in a
> > post but groups are the best way I can think of handling all the
iterations.
> > However the limits of groups is what is killing me now.
>
> I'm interested in understanding you situation better -
> How about a picture:
>
> OS level
>
> ----------------------------------------------------------------
> | system task |
> +-------------------+-----------------------+------------------+
> | client 1 | client 2 | client n |
> +--------+----------+--------+--------+-----+--------+---------+
> | sub 1 | sub 2 | sub x1 | sub x2 | ... | sub y1 | sub yn |
> +--------------------------------------------------------------+
>
> and the relationsips:
>
> client 1 can see sub1 and sub 2
> sub1 cannot see client 1, and should not see sub 2?
> sub2 cannot see client 1, and should not see sub 1?
>
> client 1 cannot see client 2 through client n
>
> Support crosses the table by combining the access rights of
> client 1 + sub 1 + sub 2 and their own "group" (where
> client 1 + sub 1 + sub 2 is a supported client) and may
> be combined with more than one client.
>
> The two lines with question marks are because if sub1 and sub2 can see
> client 1 then they will be able to see each other indirectly since they
> will both be members of the group of client1 and be able to exchange
> or view data generated by client 1 from either side.
>
> This is starting to look like the "chinese wall" security model, which
> UNIX (and most systems) cannot support. It may be closely related to a
> "privacy" model that isolates/distributes functions across boundaries.
>
> It may be supported, in part, by compartmentalization, which does handle
> the base diagram shown above.
>
> > Since most of the access to this system in non-interactive (handled by
FTP,
> > or daemon processes) in chrooted environments
> > most user-based solutions (sudu, et al) get sticky or
> > non-usable/maintainable.
> >
> > The post that Frank came up with patching the kernel & glibc seems to be
the
> > best route. I'm trying to aquire a PC system
> > to test it on this week. If all goes well it will be in production
shorly
> > after.
>
> Quite likely you will also have to rebuild the daemons and applications
> since the library interface may be changing (sizes of some
structs/arrays).
>
> You might be able to do something with access control lists that may
> help. ACLs allows for dynamically modifing the "group" list by listing
> the individual users that are allowed access. (see
"http://acl.bestbits.at/"
> which provides patches to ext2 for ACLs.) This may help by eliminating
> a rebuild of library and applications.
>
> If rebuilding becomes too complex to support, you might look at the
> RSBAC project which implements/supports more security models under Linux
> than any other security project I've run across. I don't say use it, but
> you can look it over at "http://www.rsbac.de/". I've found the site
maintainer
> very willing to answer questions and help out (Amon Ott). He is
technically
> oriented toward security, and the details of the documentation provided at
> the site is mathmatically oriented.
>
> Solaris does have a "trusted Solaris" product that provides similar
> compartmentalization (a compartment for the client, groups for the subs.
> groups can be re-used since the compartment isolation prevents sharing
> from sub 1 to sub x or sub y). The problem with only using compartments
> is when sub1 IS sub x. That is where the chinese wall appears - I've not
> seen any implementation of that.
>
> In both cases there is a limit of 64 compartments on a system.
>
> The advantage of using compartments is that they are mandatory (where
group
> is discretionary) and it prevents the users from setting world access.
> World access in a compartment really just means "anyone in the
compartment".
> Group access is "anyone in the compartment and in the group".
>
> I've tried to list these in order of increasing difficulty/expense. My
guess
> is that the ACL route would be the easiest and least intrusive to
utilities
> and daemons. And possibly the easiest to understand.
>
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: pollard@navo.hpc.mil
>
> Any opinions expressed are solely my own.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:16 EST