Re: [Xen-devel] Re: [Xense-devel] [XSM:ACM][PATCH] nulldereference bug fix

["George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>]

On Fri, 2007-09-28 at 10:21 -0400, Stefan Berger wrote:

> The problem is that the roll-back related to chinese wall must *only*
> be done when the check on the chinese wall was successful and NOT when
> it was not successful. 
> Following the test Syunsuke HAYASHI describes in 
> 
> http://lists.xensource.com/archives/html/xen-devel/2007-09/msg00514.html 
> 
> 
> I get the following after creating the 1st domain when doing an 'xm
> dumppolicy': 
> 
> 
> 
> Policy dump:
> ============
> POLICY REFERENCE = example.client_v1.
> PolicyVer = 8c000000.
> XML Vers. = 1.24
> Magic     = 1debc.
> Len       = 178.
> Primary   = CHINESE WALL (c=1, off=40).
> Secondary = SIMPLE TYPE ENFORCEMENT (c=2, off=b8).
> 
> 
> Chinese Wall policy:
> ====================
> Policy version= ffffe849.
> Max Types     = 4.
> Max Ssidrefs  = 7.
> Max ConfSets  = 1.
> Ssidrefs Off  = 24.
> Conflicts Off = 5c.
> Runing T. Off = 64.
> C. Agg. Off   = 6c.
> 
> SSID To CHWALL-Type matrix:
> 
>   ssidref 0:  00 00 00 00 
>   ssidref 1:  00 00 00 01  <-- Domain-0
>   ssidref 2:  00 01 00 00 
>   ssidref 3:  01 00 00 00 
>   ssidref 4:  00 00 01 00 
>   ssidref 5:  00 00 00 01 
>   ssidref 6:  00 00 00 01 
> 
> Confict Sets:
> 
>   c-set 0:    01 00 01 00 
> 
> Running
> Types:         00 00 01 01 
> 
> Conflict
> Aggregate Set: 01 00 00 00 
> 
> 
> Simple Type Enforcement policy:
> ===============================
> Policy version= cef6c202.
> Max Types     = 6.
> Max Ssidrefs  = e.
> Ssidrefs Off  = 14.
> 
> SSID To STE-Type matrix:
> 
>   ssidref 0: 00 00 00 00 00 00 
>   ssidref 1: 01 01 01 01 01 01  <-- Domain-0
>   ssidref 2: 01 00 00 00 00 00 
>   ssidref 3: 00 01 00 00 00 00 
>   ssidref 4: 00 00 00 00 01 00 
>   ssidref 5: 01 01 01 00 01 00 
>   ssidref 6: 00 01 00 01 01 00 
>   ssidref 7: 00 00 01 00 00 00 
>   ssidref 8: 00 00 00 00 00 01 
>   ssidref 9: 00 00 00 01 00 00 
>   ssidref a: 00 00 00 00 01 00 
>   ssidref b: 00 01 00 00 00 00 
>   ssidref c: 00 00 00 00 00 01 
>   ssidref d: 00 00 00 00 01 00 
> 
> 
> 
> 
> This is output is correct. 
> 
> 
> After trying to start the 2nd domain I now get: 
> 
> 
> 
> Policy dump:
> ============
> POLICY REFERENCE = example.client_v1.
> PolicyVer = 0.
> XML Vers. = 1.24
> Magic     = 1debc.
> Len       = 178.
> Primary   = CHINESE WALL (c=1, off=40).
> Secondary = SIMPLE TYPE ENFORCEMENT (c=2, off=b8).
> 
> 
> Chinese Wall policy:
> ====================
> Policy version= 100ff00.
> Max Types     = 4.
> Max Ssidrefs  = 7.
> Max ConfSets  = 1.
> Ssidrefs Off  = 24.
> Conflicts Off = 5c.
> Runing T. Off = 64.
> C. Agg. Off   = 6c.
> 
> SSID To CHWALL-Type matrix:
> 
>   ssidref 0:  00 00 00 00 
>   ssidref 1:  00 00 00 01  <-- Domain-0
>   ssidref 2:  00 01 00 00 
>   ssidref 3:  01 00 00 00 
>   ssidref 4:  00 00 01 00 
>   ssidref 5:  00 00 00 01 
>   ssidref 6:  00 00 00 01 
> 
> Confict Sets:
> 
>   c-set 0:    01 00 01 00 
> 
> Running
> Types:         ffff 00 01 01 
> 
> Conflict
> Aggregate Set: 01 00 ffff 00 
> 
> 
> Simple Type Enforcement policy:
> ===============================
> Policy version= 0.
> Max Types     = 6.
> Max Ssidrefs  = e.
> Ssidrefs Off  = 14.
> 
> SSID To STE-Type matrix:
> 
>   ssidref 0: 00 00 00 00 00 00 
>   ssidref 1: 01 01 01 01 01 01  <-- Domain-0
>   ssidref 2: 01 00 00 00 00 00 
>   ssidref 3: 00 01 00 00 00 00 
>   ssidref 4: 00 00 00 00 01 00 
>   ssidref 5: 01 01 01 00 01 00 
>   ssidref 6: 00 01 00 01 01 00 
>   ssidref 7: 00 00 01 00 00 00 
>   ssidref 8: 00 00 00 00 00 01 
>   ssidref 9: 00 00 00 01 00 00 
>   ssidref a: 00 00 00 00 01 00 
>   ssidref b: 00 01 00 00 00 00 
>   ssidref c: 00 00 00 00 00 01 
>   ssidref d: 00 00 00 00 01 00 
> 
> 
> 
> Obviously the 'Running Types' and 'Conflict Aggregate Set' are showing
> wrong numbers due to the state on the chinese wall having been rolled
> back, although it should not have been. Also, the reason why this
> operation was protected through the surrounding lock is that while
> this test happens no policy change may occur, which would recalculate
> all the state. So I'd rather have this unrolling left where it was. 
> 

> > 
> > > static inline int acm_domain_create(struct domain *d, ssidref_t
> > > ssidref)
> > > {
> > >    void *subject_ssid = current->domain->ssid;
> > >    domid_t domid = d->domain_id;
> > >    int rc;
> > > 
> > >    read_lock(&acm_bin_pol_rwlock);
> > >    /*
> > >       To be called when a domain is created; returns '0' if the
> > >       domain is allowed to be created, != '0' if not.
> > >     */
> > >    rc = acm_init_domain_ssid(d, ssidref);
> > >    if (rc != ACM_OK)
> > >        goto error_out;
> > > 
> > >    if ((acm_primary_ops->domain_create != NULL) &&
> > >        acm_primary_ops->domain_create(subject_ssid, ssidref,
> domid)) {
> > >        rc = ACM_ACCESS_DENIED;
> > >    } else if ((acm_secondary_ops->domain_create != NULL) &&
> > >                acm_secondary_ops->domain_create(subject_ssid,
> ssidref,
> > >                                                 domid)) {
> > >        /* roll-back primary */
> > >        if (acm_primary_ops->domain_destroy != NULL)
> > >            acm_primary_ops->domain_destroy(d->ssid, d);
> > >        rc = ACM_ACCESS_DENIED;
> > >    }
> > > 
> > >    if ( rc == ACM_OK )
> > >    {
> > >        acm_domain_ssid_onto_list(d->ssid);
> > >    } else {
> > >        acm_free_domain_ssid(d->ssid);
> > >    }
> > > 
> > > error_out:
> > >    read_unlock(&acm_bin_pol_rwlock);
> > >    return rc;
> > > } 
> > > 

Ok, but then the null dereference issue still exists within the context
of XSM.  The options are:

1) Follow acm_free_domain_ssid(d->ssid) with d->ssid = NULL
(I've tested this and it maintains the desired policy state:

Confict Sets:

   c-set 0:    00 01 00 01

Running
Types:         01 01 00 00

Conflict
Aggregate Set: 00 00 00 01

but seems less attractive from a coding style perspective)

or 

2) Chance acm_free_domain_ssid to pass d instead of ssid and ensure that
d->ssid = NULL in acm_free_domain_ssid.

George

_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel