lkml.org 
[lkml]   [2000]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.039 / U:1.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site