Andy Warner wrote:
>
>
> Please don't take my lack of asking for new object classes as anything
> other than ignorance as to how things "work" in the open source
> community. All of our previous work has been on proprietary MLS systems.
> The idea of asking an OS vendor or community to add features for my
> needs was foreign to me. Plus, my time constraints on the project may
> not have allowed it. I have found this community to be very open and
> helpful and always planned to give some input as to the need for these
> object classes after my project was finished (which is now).
>>
Fair enough. I'm happy to see additional efforts in this arena, regardless.
>>> So, internally, the access checks on the database and catalog are
>>> performed when those objects are opened. During the actual create table
>>> operation we have two calls to avc_has_perm, the first checks the
>>> client's context, schema's context for dir {search add_name} and the
>>> second checks the client's context, table's context for db_table {create}
>>>
>>> Could you elaborate on what you mean by "I don't think it is a good idea
>>> to muddle the object
>>> class ownership concept by doing checks for classes which are owned by
>>> another
>>> object manager" ? In what way is an object class *owned* by an object
>>> manager? I'm a newbie in this area and would appreciate some
>>> constructive criticism.
>>>
>>>
>>
>> So, overloading object classes leads to confusion and other issues. For example,
>> if an actual directory got labeled what the internal catalog was labeled then
>> the client would have access to that, even if that wasn't the intention. There
>> also may be conflicting type_transition rules because you end up wanting one
>> object label transition to be different from another when used on the different
>> kinds of objects.
>>
> Yep, I can see that as an issue. Practically speaking, I would think the
> new object classes will be added before any such real issue arose. But,
> isn't there a similar issue, say, between a system with a sepostres
> policy and a Trusted RUBIX installation on the same platform? I have
> already bumped up against some of the type_transition rules for sepostgres.
>> The flask architecture was originally implemented in a microkernel where object
>> managers were services that enforced access per the security servers decision.
>> In that architecture an object manager would be responsible for the object class
>> it was enforcing access on. Stephen can correct me here if I'm wrong but I
>> object to object class overloading based on these issues.
>>
>
You shouldn't really bump in to each other since the dbms domain and objects
should all be labeled differently, what have you seen happen?
> In your terminology, because rubix is enforcing the policy, would it be
> considered an object manager? And, if so, wouldn't seposgres also be
> considered one? where they both enforce access to the same set of object
> classes?
Yes, both rubix and sepostgres are object managers. abstract object classes
where there isn't a single owner are interesting, I'd expect different object
labeling in most cases so it doesn't matter. In the case of the data in both
being equivalent from a security POV maybe it actually does make sense for them
to share labels and object classes (especially true if the database is primarily
enforcing an MLS policy)
>>
>>>> Were the db object classes incomplete for you so you needed to use filesystem
>>>> object classes? I'm trying to get a feeling for what the motivation was behind
>>>> these checks.
>>>>
>>>>
>>> Yes, if the db object classes supported schema and catalog I would not
>>> use the dir. I'm not sure what to say for motivation, other than I felt
>>> it important and useful to have security checks on our catalog and
>>> schemata. And, since these objects function very closely to an OS
>>> directory, and there was no support for the catalog and schema objects
>>> in the selinux policy, and I decided not to modify the targeted/mls
>>> policies as part of our release, I chose to use the dir object class.
>>> Actually, I think I got the idea from an old post on this newsgroup. The
>>> options presented in that post were to either modify the policy's object
>>> class and permissions or overload a pre-existing object class. I chose
>>> the latter. It was the lesser of two evils. I didn't want to have to
>>> keep up with updates to the targeted/mls policies.
>>>
>>
>> See above, you brought up another issue here where permissions being overloaded
>> may not have the same read/write mappings and therefore may be difficult to work
>> around with respect to the MLS policy. Approaching the community to work on a
>> common set of object classes/perms and getting them merged in to upstream
>> refpolicy is definitely the right answer.
>>
> I agree completely.
>>
>>>> Is Trusted RUBIX with these SELinux checks actually released, are the access
>>>> checks set in stone? I'd like to see as much consistency between dbms object
>>>> models as possible so that policy won't be dramatically different between them.
>>>>
>>>>
>>> Yes, Trusted RUBIX with these security checks is released. But no, they
>>> are not set in stone. The minute a new policy is released supporting the
>>> db_schema and db_catalog object classes will be the time I change our
>>> product to use them, and stop using the dir object class.
>>>
>>>
>>
>> Good. Hopefully we can get this worked out between you guys and have a
>> consistent (and documented) set of permissions that make it easy to write policy
>> that works on both systems (as much as possible)
>>
> I think that is well on its way. One question out of curiosity. Would
> you anticipate that I should or would use the seposgres TE rules that
> already exist in the targeted/mls policy? I ask that from your comment
> about writing policy that that works on both systems. With current state
> of things this seems very difficult, though, I think a higher level
> interface set, like the one we created for the object set, could be made
> that, for the most part, worked for both systems.
>>
Yes, I don't mean they'd be using an identical policy but shared
templates/interfaces that worked with both would certainly make it easier to
target both systems without really needing to know the intricacies of each
systems enforcement.
>>> To my knowledge there are only two DBMS's that integrate SELinux into
>>> its product, SEPostgresql and Trusted RUBIX. I'm not so sure I would say
>>> our DBMS object models are dramatically different. SEPostgresql does
>>> not have a catalog object and chose not to have selinux control over
>>> their schema object. From looking at KaiGai's work and posts I think in
>>> the future they will support the schema object, in much the same way I
>>> tried to in our current release.
>>>
>>
>> They chose not to for now, the initial set of permissions used by SEPostgres
>> looks like it is going to be minimal, unfortunately, but should evolve into
>> something more comprehensive.
>>
>> I may be missing it but do you support 'domain-like' type_transitions for stored
>> procedures? This was one of the more interesting features in the initial
>> sepostgres patches IMHO because it allowed for trusted stored procedures that
>> can read tables the client couldn't necessarily read, and could do operations on
>> them before handing over the data (eg., fuzzing of coordinates)
>>
> We do not implement stored procedures at all, though this is a near
> future possibility. As I said before, our background is MLS and often in
> the EAL-5+ type (old B3). The group-think was always that stored
> procedures were too insecure for such assurance levels. But, I have been
> pushing the possibility in a EAL-4 type mode, for exactly the reasons
> you mentioned above. With the selinux domain transition concept a stored
> procedure becomes very interesting.
>> --
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
