Hi Joshua, Joshua Brindle 写道: > Harry Ciao wrote: >> Hi Steve, >> >> Steve Lawrence 写道: >>> However, I did find what appears to be an unrelated problem. It looks >>> like the role attributes are getting written to the policy db as if >>> they >>> were roles. I don't think this will break anything (I think), but >>> considering that the kernel doesn't know anything about >>> role_attributes, >>> it seems odd to me that they are in the binary. >>> >>> Note: I found this by looking at a downgraded policy.24 in apol, so >>> this >>> could potentially be a downgrade issue. But from looking at the code, I >>> believe role attributes are being written as if they're roles. >>> >>> - Steve >>> >>> >>> >> You are right! >> >> The role attribute's destination would have been fulfilled at the expand >> stage when its types.types ebitmap populated to all its sub regular >> roles, thus there is no need to write role attribute's role_datum_t to >> policy.X at all. This won't cause any harm, but redundant. >> >> We could bail out from role_write() when finding out the current datum >> is a role attribute while writing to policy.X. I would send out a patch >> later today. >> >> BTW, I'd also noticed role attribute by apol but I didn't realize what >> you have realized, so it's always beneficial to have others review your >> patches :-) >> > > When downgrading a policy I believe the downgraded policy should be > identical (e.g., binary diffable or very close if not possible) to the > older toolchain. In this case I don't see a reason why the downgraded > policy should have the role_attributes in the role symtab. There > should be a patch to correctly discard them when downgrading IMO. > I am creating a patch to skip role attributes from writing to policy.X, so there won't be any role attributes contained in policy.X, no matter what X is. Even if a policy downgrade happens while loading policy.X, we don't have to worry about discarding role attributes at all, since it won't exist in policy.X anyway:-) Thanks, Harry -- 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.
