Perché SMF manifest sta perdendo i dati di configurazione quando viene esportato su SmartOS?


10

Sto eseguendo un processo server in SMF (Server Management Facility) sull'immagine SmartOS Base64 1.8.1 di Joyent.

Per coloro che non sono esperti di SmartOS, si tratta di una distribuzione basata su cloud di IllumOS con KVM. Ma essenzialmente è come Solaris ed eredita da OpenSolaris. Quindi, anche se non hai usato SmartOS, spero di sfruttare alcune conoscenze di Solaris su ServerFault.

Il mio problema è che desidero consentire a un utente non privilegiato di riavviare un servizio di sua proprietà. Ho scoperto come farlo utilizzando RBAC e aggiungendo un'autorizzazione /etc/security/auth_attre associando tale autorizzazione al mio utente.

Ho quindi aggiunto quanto segue al mio manifest SMF per il servizio:

<property_group name='general' type='framework'>
  <!-- Allow to be restarted-->
  <propval name='action_authorization' type='astring'
    value='solaris.smf.manage.my-server-process' />
  <!-- Allow to be started and stopped -->
  <propval name='value_authorization' type='astring'
    value='solaris.smf.manage.my-server-process' />
</property_group>

E questo funziona bene quando importato. Il mio utente senza privilegi è autorizzato a riavviare, avviare e arrestare il proprio processo del server (questo è per le distribuzioni automatizzate di codice).

Tuttavia, se esporto il manifest SMF, questi dati di configurazione spariranno ... tutto ciò che vedo in quella sezione è questo:

<property_group name='general' type='framework'>
  <property name='action_authorization' type='astring'/>
  <property name='value_authorization' type='astring'/>
</property_group>

Qualcuno sa perché questo sta accadendo? La mia sintassi è sbagliata o sto semplicemente usando SMF in modo errato?


1
Hmmm I commenti sembrano essere svaniti da qui senza parola o menzione.
Redsquare,

Risposte:


16

Perché svccfg (1M) è rotto e l'ho rotto.

Nel 2007, ho aggiunto una funzionalità a SMF che consentiva a gruppi di proprietà che potevano contenere informazioni riservate, leggibili solo da utenti con privilegi appropriati. L'idea era che si potesse aggiungere una proprietà "read_authorization" a un gruppo di proprietà e chiunque non fosse né privilegiato (sostanzialmente, root) né in possesso di una delle autorizzazioni nominate da quella proprietà non sarebbe in grado di leggere i valori di alcuna proprietà nel gruppo. Questo è stato integrato nell'ambito di questo commit ed è utilizzato (almeno) dai prodotti di archiviazione Sun ZFS per archiviare elementi come le password LDAP.

Nell'ambito di tale lavoro, volevamo assicurarci che anche gli utenti privilegiati in grado di leggere questi valori non li avrebbero esposti accidentalmente esportando lo stato di un servizio o creando un archivio del repository SMF. Quindi ho aggiunto il flag '-a' ai comandi export e archive in svccfg che avrebbero esportato esplicitamente tutti i valori delle proprietà e ho modificato il valore predefinito per escludere quelli che erano protetti da lettura.

Sfortunatamente, questa restrizione non viene applicata correttamente; in questo caso, semplicemente rifiutiamo di esportare qualsiasi proprietà tranne alcune selezionate nel gruppo di proprietà "generale" con valori. Il resto viene esportato senza alcun valore, che è quello che stai vedendo. E sfortunatamente, usare l'opzione -a non aiuta qui, perché quando raggiungiamo il punto rilevante, non abbiamo più il contesto richiesto per sapere che l'hai superato. È persino giusto chiedersi se questo flag debba essere richiesto per esporre questi valori: l'identità delle autorizzazioni che consentono di cambiare lo stato del servizio è effettivamente sensibile e sarebbe utile per un aggressore. Non c'era dubbio che avevo in mente quando ho scritto questo, ed è ragionevole limitarlo dal punto di vista degli altri a meno che non sia esplicitamente desiderato. Ma nelle versioni precedenti di S10, l'XML esportato e gli archivi lo contenevano, quindi è stato sicuramente un cambiamento incompatibile. Saresti perdonato per esserti arrabbiato per questo. Ma il vero problema qui è che -a non funziona quando il gruppo di proprietà in questione è "generale". Come sei la prima persona a colpire questo non ne ho idea.

Puoi seguire questo problema alla sua pagina, qui . Nel frattempo, puoi considerare di aggirarlo aggiungendo manualmente i valori delle proprietà nell'XML generato. Nota che puoi anche leggerli tramite svcprop (1) se necessario. Hai le mie scuse. Grazie a Deirdre Straughan per avermi portato questa domanda alla mia attenzione.


1
Wow. Grazie Keith. Dato che sei il ragazzo che ha scritto il codice originale, sono abbastanza sicuro di poter contrassegnare questa risposta come corretta :-) Grazie mille per lo sfondo dettagliato di questo problema.
Scott,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.