KaiGai Kohei wrote: > Joshua Brindle wrote: >> KaiGai Kohei wrote: >>> The following patch is revised one for libsepol. >>> >>> Updates: >>> - The properties of type_datum are packed within the third word of >>> type entries in the kernel policy. >>> The first bit (TYPEDATUM_PROPERTY_PRIMARY) means the entry is a >>> primary type, and the second bit (TYPEDATUM_PROPERTY_ATTRIBUTE) >>> means the entry is an attribute. >>> >> >> I didn't see an answer in the current threads, and this looks like > > the latest userland patch series so I'll ask here: What is > the purpose > of the properties? We can infer what it knows > from the other fields >> in the datum, right? > > Stephen said as follows: > http://marc.info/?l=selinux&m=121882413424973&w=2 > >> Keeping the type attribute names in the types symtab in the kernel >> policy allows tools like audit2why and apol to extract the original >> attribute names and display them. I originally shed them because the >> kernel didn't need to use that information and we don't want >> attribute names to be used in security contexts, but it costs us >> little to save them and check for them, and it benefits the tools. > No, I got that part. What I was missing was that we identified attributes differently in modules and kernel policy now, kind of confusing. > The purpose of property bits is to identify the sort of type_datum. > The kernel policy version >= 24 allows to load attribute > entries, so we have to distinguish them from existing type entries. > > Any type_datum entries of attributes were removed at the tail > of expand_module in the older version, so we can assume any > entries loaded to kernel space are primary or alias type. > Because existing format of type_datum does not have any > information to identify it to be an attribute, we had to add > a flag bit to mark. > >> One thing that bothers me is that we read prop out of the binary but > > it is nowhere in the type datum, I can see this leading to > errors in > the reader where a developer can't figure out > where the extra data is > coming from. > > (?_?) I'm not sure about your concern. > > The type_datum has the following format in the newer kernel policy: > > +0 +-------------------------+ > | length of name | > +4 +-------------------------+ > | type identifier value | > +8 +-------------------------+ > | property bits | <--- TYPEDATUM_PROPERTY_PRIMARY > +12 +-------------------------+ TYPEDATUM_PROPERTY_ATTRIBUTE > | bounds type identifier | > +16 +-------------------------+ > | text representation of | > | name (variable length) | > +-------------------------+ > > Any property bits are packed within the third field. > I don't see that in the libsepol patch: @@ -145,8 +146,16 @@ ebitmap_t types; /* types with this attribute */ #define TYPE_FLAGS_PERMISSIVE 0x01 uint32_t flags; + uint32_t bounds; /* bounds type, if exist */ } type_datum_t; > >> I will echo Steve's request to remove the old hierarchy stuff from >> here > > and add in the implementation necessary to do validation > of the bounds > in libsepol. > > OK, please wait for a few days. > > Thanks, -- 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.
