Messages in this thread | | | From | "List User" <> | Subject | Re: 2.2.* kernels w/ glibc-2.1.* allowing ngroups_max to be > 128? | Date | Tue, 8 Aug 2000 20:29:34 -0500 |
| |
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/
| |