RE: [RFC][PATCH] selinux: introduce support for deferred mappingof inode security contexts

RE: [RFC][PATCH] selinux: introduce support for deferred mappingof inode security contexts

[Joshua Brindle]

> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> Sent: Tuesday, May 16, 2006 8:16 AM
> 
> On Mon, 2006-05-15 at 12:35 -0400, Stephen Smalley wrote:
> > # touch foo
> > # chcon -t foo_exec_t foo
> > # ls -Z foo
> > -rw-r--r--  root root system_u:object_r:unlabeled_t    foo
> 
> Note that an alternative would be to modify 
> security_sid_to_context() to return the unmapped string 
> representation if it exists rather than just falling through 
> to the unlabeled SID's context.  In that case,
> getxattr() would return the unmapped string, and userspace 
> would see user_u:object_r:foo_exec_t throughout the example 
> even though the kernel would internally be applying access 
> checks based on the unlabeled SID's context.  That seems 
> useful for programs that want to check the attributes (e.g. 
> restore), but prevents rpm from easily checking whether the 

In the restore case it is much more about what is on the physical disk
than what the kernel sees and that information is easy to obtain. If
this returns the unmapped string doesn't it make the canonicalization
fairly useless?

> attribute has been validated by a subsequent policy load 
> (although it could use security_check_context(3) for that 
> purpose).  Likewise, if an audit message is generated for a 
> SID that has been invalidated, having 
> security_sid_to_context() return the unmapped string 
> representation would preserve the original string label in 
> the audit message rather than degenerating to the unlabeled 
> SID's context.

I think it would be very confusing to have conflicting audit messages
(eg., avc says one thing, audit message says another) however, it is
probably very important to be able to audit privlabel events and be able
to see the unmapped context in an audit message, is that possible?

Joshua Brindle


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [RFC][PATCH] selinux: introduce support for deferred mappingof inode security contexts

[Stephen Smalley]

On Tue, 2006-05-16 at 08:50 -0400, Joshua Brindle wrote:
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> > Note that an alternative would be to modify 
> > security_sid_to_context() to return the unmapped string 
> > representation if it exists rather than just falling through 
> > to the unlabeled SID's context.  In that case,
> > getxattr() would return the unmapped string, and userspace 
> > would see user_u:object_r:foo_exec_t throughout the example 
> > even though the kernel would internally be applying access 
> > checks based on the unlabeled SID's context.  That seems 
> > useful for programs that want to check the attributes (e.g. 
> > restore), but prevents rpm from easily checking whether the 
> 
> In the restore case it is much more about what is on the physical disk
> than what the kernel sees and that information is easy to obtain. If
> this returns the unmapped string doesn't it make the canonicalization
> fairly useless?

IIUC, restore -C works by calling lgetxattr() on the files and comparing
the attribute returned by it against what is in the dump.  So if
lgetxattr() returns unlabeled_t rather than the unmapped string, the
compare will fail.  Likewise for verification of a successful restore
from a dump.  IIUC, the raw read of the device only occurs when dumping
the partition; restore itself operates via the normal system calls on
the fs.

Canonicalization would still occur for contexts that are valid; the only
change here is in what we return to userspace (and in logs) for invalid
contexts.

> > attribute has been validated by a subsequent policy load 
> > (although it could use security_check_context(3) for that 
> > purpose).  Likewise, if an audit message is generated for a 
> > SID that has been invalidated, having 
> > security_sid_to_context() return the unmapped string 
> > representation would preserve the original string label in 
> > the audit message rather than degenerating to the unlabeled 
> > SID's context.
> 
> I think it would be very confusing to have conflicting audit messages
> (eg., avc says one thing, audit message says another) however, it is
> probably very important to be able to audit privlabel events and be able
> to see the unmapped context in an audit message, is that possible?

At present, both the avc and audit will end up displaying the unlabeled
SID's context for all invalid contexts because that is what
security_sid_to_context() will return.  What I'm suggesting would change
that behavior so that they both will display the unmapped string
representation, thereby preserving the actual text label.
 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC][PATCH] selinux: introduce support for deferred mappingof inode security contexts

[Joshua Brindle]

Stephen Smalley wrote:
> On Tue, 2006-05-16 at 08:50 -0400, Joshua Brindle wrote:
>   
> <snip>
> IIUC, restore -C works by calling lgetxattr() on the files and comparing
> the attribute returned by it against what is in the dump.  So if
> lgetxattr() returns unlabeled_t rather than the unmapped string, the
> compare will fail.  Likewise for verification of a successful restore
> from a dump.  IIUC, the raw read of the device only occurs when dumping
> the partition; restore itself operates via the normal system calls on
> the fs.
>
>   
I'm not sure if this is the appropriate behavior. For example, restore 
doesn't/can't verify that the UID/GID for the file being restored is 
mapped the same as it was when the archive was created. IMHO restore's 
job isn't to interpret the backup, its job is to write it out and let 
the admin interpret it.

> Canonicalization would still occur for contexts that are valid; the only
> change here is in what we return to userspace (and in logs) for invalid
> contexts.
>
>   
>> <snip>
>
> At present, both the avc and audit will end up displaying the unlabeled
> SID's context for all invalid contexts because that is what
> security_sid_to_context() will return.  What I'm suggesting would change
> that behavior so that they both will display the unmapped string
> representation, thereby preserving the actual text label.
>   

So the denial would have the unmapped context? I don't think I 
understand that, it wouldn't be a denial that represents what actually 
happened (not to mention the type wouldn't necessarilly be in the policy 
so any attempt to audit2allow or similar will yield an 
uncompilable/unlinkable policy)

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC][PATCH] selinux: introduce support for deferred mappingof inode security contexts

[Stephen Smalley]

On Tue, 2006-05-16 at 10:02 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Tue, 2006-05-16 at 08:50 -0400, Joshua Brindle wrote:
> >   
> > <snip>
> > IIUC, restore -C works by calling lgetxattr() on the files and comparing
> > the attribute returned by it against what is in the dump.  So if
> > lgetxattr() returns unlabeled_t rather than the unmapped string, the
> > compare will fail.  Likewise for verification of a successful restore
> > from a dump.  IIUC, the raw read of the device only occurs when dumping
> > the partition; restore itself operates via the normal system calls on
> > the fs.
> >
> >   
> I'm not sure if this is the appropriate behavior. For example, restore 
> doesn't/can't verify that the UID/GID for the file being restored is 
> mapped the same as it was when the archive was created. IMHO restore's 
> job isn't to interpret the backup, its job is to write it out and let 
> the admin interpret it.

Yes, restore doesn't check what the uid maps to (i.e. it doesn't look up
the username); it just gets the uid via lstat() and compares with what
is in the dump IIUC.  Likewise for the attribute, using lgetxattr().
But with the current patch, the lgetxattr() will still return
unlabeled_t for these not-yet-valid contexts, and thus won't match the
value in the dump.

This is all based on the description in the bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189845

Now, if we don't plan to use this technique for restore at all, instead
just using Chad's proposed approach, then it may not matter.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189845#c27
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189845#c30

Part of the problem here is the overloading of lgetxattr().  Having two
separate calls (one for getting the raw on-disk attribute and one for
getting the MAC label as seen incore) would be nice, but not too likely
at this point.

> > At present, both the avc and audit will end up displaying the unlabeled
> > SID's context for all invalid contexts because that is what
> > security_sid_to_context() will return.  What I'm suggesting would change
> > that behavior so that they both will display the unmapped string
> > representation, thereby preserving the actual text label.
> >   
> 
> So the denial would have the unmapped context? I don't think I 
> understand that, it wouldn't be a denial that represents what actually 
> happened (not to mention the type wouldn't necessarilly be in the policy 
> so any attempt to audit2allow or similar will yield an 
> uncompilable/unlinkable policy)

Strictly speaking, that is already possible when running audit2allow or
audit2why on an audit log generated while running a different policy.
And it isn't clear that you want audit2allow automatically converting a
denial on a not-yet-valid (or previously valid) context into access to
unlabeled_t, but that is another matter.  But you seem to be unhappy
with either alternative (avc and audit both log the unmapped string, avc
and audit log different values).  So you think they should just continue
to log unlabeled_t in both cases?  That loses information that we have
available with this change.  Possibly they could log both, but that
becomes a format change to the audit messages.

Going back to your earlier comment, you asked about auditing labelpriv
events and being able to see the unmapped context in an audit message.
We can certainly auditallow labelpriv in the policy to trigger an audit
message on each one, although that wouldn't include the unmapped context
value.  I presently have printk(KERN_INFO) statements when an unmapped
value is first added to the SID table and when contexts switch from
mapped to unmapped or vice versa upon policy reload; those could be
converted to audit_log calls if that is preferable.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [RFC][PATCH] selinux: introduce support for deferred mappingof inode security contexts

[Joshua Brindle]

> From: Jeremy Katz [mailto:katzj@redhat.com] 
> 
> On Tue, 2006-05-23 at 13:15 -0400, Stephen Smalley wrote:
> > Below is an updated version of the kernel patch to support rpm 
> > labeling of files before policy load, with a couple of bug 
> fixes and a 
> > re-base to 2.6.17-rc4-mm3.  Note that before we can 
> upstream this, we 
> > need to resolve the issues of how rpm will check file label 
> validity 
> > after policy load (e.g. calling security_check_context(3) on each 
> > label from the header), what corrective action rpm will 
> take if a file 
> > label is invalid (options suggested include relabeling to 
> unlabeled_t, 
> > relabeling to the context returned by the system policy via 
> > matchpathcon, or reverting the install), and the issues 
> raised by Karl 
> > above (as they also affect the ability of rpm to perform such 
> > verification and correction sanely).
> 
> Well, given that the only labels that will end up in a header 
> will be from a policy in that package, I'm still not really 
> convinced what adding a verification step _really_ accomplishes.  
> 

There are a number of reasons the policy module insertion can fail. The
package and the base being out of sync, for example as we saw last week.
The policy server (when its deployed) denying the policy addition.
Assertion violations, hierarchical assertion violations, mutual
dependancies between modules (which you will hit btw, since you are
installing them one at a time), conflicting modules, the list goes on.

By leaving bogus labels on the filesystem you add an attack vector where
future (possibly legitimate) policy can change the behavior of the
on-disk labels (transisions, etc). Further the application you just laid
down will probably be unusable. Even if unconfined_t can execute the
unlabeled apps other labels may be affected. For example, if passwd gets
laid down with a bogus label and an unconfined user runs it (in
unconfined_t since there won't be a transition) then the shadow label
will be lost and the shadow file will be accessible to confined domains
(eg., apache).



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [RFC][PATCH] selinux: introduce support for deferred mappingof inode security contexts

[Joshua Brindle]

> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> 
> On Thu, 2006-05-25 at 11:19 -0400, Stephen Smalley wrote:
> > The alternative model to post checking after policy load would be to
> > either:
> > 1) Precheck the file contexts from the header against the 
> .pp file in 
> > some manner at install time (in which case rpm can abort early), or
> 

I'm not sure this works. As noted earlier the policy module insertion
can fail for a number of reasons so the labels would still be
inconsistent after installation (even if they were valid in the module).
Further its very tricky to determine whether a label is valid without
going through a full link/expand since the role types, attributes, etc
need to be expanded to decide if labels are valid.

> And as I suspect that you'll say that since those contexts 
> were generated from the .pp file in the first place, no such 
> checking is required, let me note that:
> a) the contexts will have been generated from the file 
> contexts part of the .pp, not from the policy module itself, 
> so there could be an inconsistency between the two that 
> leaves the context invalid under the new policy, and
> b) having rpm recheck at install time provides us with both 
> greater robustness (in the event of a bug in rpmbuild or a 
> package corrupted in some manner along the way) and security 
> (in the event of a maliciously constructed package).
> 
> > 2) Have load_policy fail if any of these labelpriv-created contexts 
> > were not made valid by the new policy, reverting to the old 
> policy and 
> > returning an error all the way back to rpm (in which case rpm still 
> > has to take some corrective action).
> 

Implemented in the kernel? (trying to think this through) the sidtab
will be updated with the symbolic labels of the files but mapped to
unlabeled, the reload would check any label<->symbolic inconsistencies.
If a policy reload invalidates a label do you store the symbolic version
of it? If so how can you tell the difference between labels created with
labelpriv or otherwise invalidated labels?


I agree that this is very important from a robustness POV, specifically
the propagation of label inconsistencies that will happen if executables
stay unlabeled on the filesystem and therefore are unaffected by the
type_transition rules that would normally apply to them (which keep the
file labels consistent). This propagation could get worse and worse as
the system runs in an inconsistent state.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [RFC][PATCH] selinux: introduce support for deferred mappingof inode security contexts

[Stephen Smalley]

On Thu, 2006-05-25 at 11:42 -0400, Joshua Brindle wrote:
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> > 
> > On Thu, 2006-05-25 at 11:19 -0400, Stephen Smalley wrote:
> > > The alternative model to post checking after policy load would be to
> > > either:
> > > 1) Precheck the file contexts from the header against the 
> > .pp file in 
> > > some manner at install time (in which case rpm can abort early), or
> > 
> 
> I'm not sure this works. As noted earlier the policy module insertion
> can fail for a number of reasons so the labels would still be
> inconsistent after installation (even if they were valid in the module).
> Further its very tricky to determine whether a label is valid without
> going through a full link/expand since the role types, attributes, etc
> need to be expanded to decide if labels are valid.

Details, details ;)  Yes, I'm not sure if this is workable, but it
seemed worth exploring.  Might even be useful on the rpmbuild side for
checking purposes.

> > > 2) Have load_policy fail if any of these labelpriv-created contexts 
> > > were not made valid by the new policy, reverting to the old 
> > policy and 
> > > returning an error all the way back to rpm (in which case rpm still 
> > > has to take some corrective action).
> > 
> 
> Implemented in the kernel? (trying to think this through) the sidtab
> will be updated with the symbolic labels of the files but mapped to
> unlabeled, the reload would check any label<->symbolic inconsistencies.
> If a policy reload invalidates a label do you store the symbolic version
> of it? If so how can you tell the difference between labels created with
> labelpriv or otherwise invalidated labels?

Yes, we'd need a separate flag in the SID table to distinguish
invalidated-by-reload vs. invalid-at-creation (labelpriv).  In the
latter case, if the context doesn't become valid upon the reload,
instead of just leaving it in the unmapped (symbolic) state, we'd bail
and return an error to the caller, leaving the old policy in place in
the kernel, and causing libsemanage to revert the store and propagate an
error back to semodule and thus to rpm.   That avoids requiring rpm to
perform any extra checking, but does still require it to perform
corrective action after having already set down the files.  It also
helps with another problem that was bothering me - the potential for the
SID table to just keep growing without bound with an endless set of
invalid file labels.  That would still be an issue for the
invalidated-by-reload contexts, so we'd still want some way to force a
purge of those, possibly a selinuxfs interface.

> I agree that this is very important from a robustness POV, specifically
> the propagation of label inconsistencies that will happen if executables
> stay unlabeled on the filesystem and therefore are unaffected by the
> type_transition rules that would normally apply to them (which keep the
> file labels consistent). This propagation could get worse and worse as
> the system runs in an inconsistent state.

Particularly since rpm itself would never see an error condition under
the current patch (w/o separate checking).

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [RFC][PATCH] selinux: introduce support for deferred mappingof inode security contexts

[Stephen Smalley]

On Thu, 2006-05-25 at 12:03 -0400, Stephen Smalley wrote:
> Yes, we'd need a separate flag in the SID table to distinguish
> invalidated-by-reload vs. invalid-at-creation (labelpriv).  In the
> latter case, if the context doesn't become valid upon the reload,
> instead of just leaving it in the unmapped (symbolic) state, we'd bail
> and return an error to the caller, leaving the old policy in place in
> the kernel, and causing libsemanage to revert the store and propagate an
> error back to semodule and thus to rpm.   That avoids requiring rpm to
> perform any extra checking, but does still require it to perform
> corrective action after having already set down the files.  It also
> helps with another problem that was bothering me - the potential for the
> SID table to just keep growing without bound with an endless set of
> invalid file labels.  That would still be an issue for the
> invalidated-by-reload contexts, so we'd still want some way to force a
> purge of those, possibly a selinuxfs interface.

Of course, since there is nothing to tie a given labelpriv event to a
given policy load, if we ever have multiple processes setting down
invalid file labels in the same window and then trying to insert
different policy modules, they could both end up failing (since neither
module would validate all of the file labels by itself), and you'd have
to insert both policy modules in a single transaction to recover.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.