Messages in this thread | | | Date | Tue, 8 Aug 2000 08:48:18 -0500 (CDT) | From | Jesse Pollard <> | 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/
| |