User who created sliver can incorrectly use other user's slice cred to do any operation on slivers

[lnevers@bbn.com]

This test scenario uses two user accounts:

• lnevers1 urn:publicid:IDN+pgeni.gpolab.bbn.com+user+lnevers1
• lnevers urn:publicid:IDN+pgeni.gpolab.bbn.com+user+lnevers

The user "lnevers" binds the user "lnevers1" to a slice. User "lnevers1" gets slice credentials and creates a sliver. User "lnevers" with the lnevers1 slice credentials executes various operations which work and should not.

Here is the test sequence:

1. As user "lnevers", used the protogeni-tests script registerslice.py to bind user "lnevers1" to a slice. The command executed:

   lnevers@sendaria:~/protogeni-tests$ ./registerslice.py --certificate=/home/lnevers/.ssl/pgeni/encrypted.pem --sa=https://www.pgeni.gpolab.bbn.com:443/protogeni/xmlrpc/sa -n bindslice lnevers1
   Got my SA credential
   No such slice registered here:Creating new slice called bindslice
   New slice created: urn:publicid:IDN+emulab.net+slice+bindslice
   Found other user record at the SA, binding to slice ...
   Bound other user to slice at the SA
   

2. User "lnevers1" gets slice credentials:

   lnevers1@sendaria:~/gcf-1.6.2$ omni.py getslicecred bindslice -o
   Result Summary: Saved slice bindslice cred to file bindslice-cred.xml
   

3. User "lnevers1" creates a sliver:

   lnevers1@sendaria:~/gcf-1.6.2$ omni.py createsliver -a insta-utah  bindslice insta.rspec --slicecredfile ./bindslice-cred.xml --api-version 2 -t GENI 3
   Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+bindslice expires 
   on 2012-08-05 00:00:00 UTC
   Reserved resources on https://boss.utah.geniracks.net/protogeni/xmlrpc/am/2.0. 
   

4. Use "lnevers" uses lnevers1 slice credentials to execute various commands which should not work. Note the credential file is renamed "lnevers1-bindslice-cred.xml" to make this capture clearer:

   lnevers@sendaria:~/gcf-1.6.2$ omni.py -a insta-utah listresources bindslice --slicecredfile ./lnevers1-bindslice-cred.xml --api-version 2 -t GENI 3 -o
   Result Summary: Retrieved resources for slice bindslice from 1 aggregates.
   Wrote rspecs from 1 aggregates to 1 files
   Saved listresources RSpec at 'unspecified_AM_URN' to file 
   bindslice-rspec-boss-utah-geniracks-net-protogeni-xmlrpc-am-2-0.xml; . 
   
   
   lnevers@sendaria:~/gcf-1.6.2$ omni.py -a insta-utah sliverstatus bindslice --slicecredfile ./lnevers1-bindslice-cred.xml --api-version 2 -t GENI 3 -o
   Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+bindslice expires 
   on 2012-08-05 00:00:00 UTC
   Saved sliverstatus on bindslice at AM https://boss.utah.geniracks.net/protogeni/xmlrpc/am/2.0 
   to file bindslice-sliverstatus-boss-utah-geniracks-net-protogeni-xmlrpc-am-2-0.json. 
   
   
   lnevers@sendaria:~/gcf-1.6.2$ omni.py -a insta-utah renewsliver bindslice --slicecredfile ./lnevers1-bindslice-cred.xml --api-version 2 -t GENI 3 -o
   Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+bindslice expires on
    2012-08-05 00:00:00 UTC
   Renewed sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+bindslice at unspecified_AM_URN (https://boss.utah.geniracks.net/protogeni/xmlrpc/am/2.0) until 
   2012-08-04T00:00:00+00:00 (UTC)
   
   lnevers@sendaria:~/gcf-1.6.2$ omni.py -a insta-utah deletesliver bindslice --slicecredfile ./lnevers1-bindslice-cred.xml --api-version 2 -t GENI 3 
   Result Summary: Deleted sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+bindslice on unspecified_AM_URN at https://boss.utah.geniracks.net/protogeni/xmlrpc/am/2.0 
   

Attaching the lnevers1 slice credentials file used by lnevers.

[lnevers@bbn.com]

Closing ticket, this is not an InstaGENI error.

This problem was due to Omni error handling problem. The test has a filename mismatch, which was not caught because Omni does not report any error when given a slice credential file name that does not exist, omni uses the credential for the user executing the command rather than reporting.

On 8/2/12 10:18 AM, Luisa Nevers wrote:

I think I have found the source of this problem. There is an Omni error, which masked the fact that the credential filename used was off by one character in my test.

When given a "--slicecredfile" argument of a non-existing file, Omni does not report a problem, I believe it simply uses the user's slice credentials.

So my test was using a "--slicecredfile" for lnevers1 that did not exist, but Omni happily executed the command with the lnevers credentials without reporting an error.

Sorry, will close the ticket and open an omni ticket.

Luisa

On 8/2/12 10:06 AM, Leigh Stoller wrote:

as lnevers re-execute sliverstatus, listresources, renewsliver and deletesliver with the lnevers1 slice credentials and it which worked as in ticket.

Hmm, that is not what the debugging shows. You executed deletesliver as lnevers with your lnevers credential.

See attached debugging email and look in the credential.

Lbs