Solaris 11.3 privilège étendu profil execve retour EOVERFLOW

Question

Je reçois l'erreur suivante lors de l'exécution java avec un profil avec une longue liste d'attributs étendus file_read:

# pfexec /usr/jdk/instances/jdk1.8.0/bin/java -cp /vagrant HelloWorld 
/usr/jdk/instances/jdk1.8.0/bin/java: Value too large for defined data type 

Quand je lance avec truss je vois l'exécutif message d'erreur est:

execve("/usr/jdk/instances/jdk1.8.0/bin/java", 0xFCEA4B60, 0xFCEA4B74) Err#79 EOVERFLOW 

La page de manuel pour execve ne liste pas EOVERFLOW comme un retour possible.

Il semble être lié au nombre d'attributs étendus file_read que je place dans le profil. Voici comment reproduire le problème. La source HelloWorld.java est trivial mais utile pour garantir que les privilèges sont attribués correctement à partir ppriv -v pid

public class HelloWorld { 
    public static void main(String[] args) { 
    System.out.println("Sleeping"); 
    try { 
     Thread.sleep(50000); 
    } catch(Exception e) { 
    } 
    System.out.println("Hello World"); 
    } 
} 

Il semble y avoir un bug dans la commande profiles ainsi que la commande profiles ne voulait pas générer une liste assez importante de file_read à hommages. Pour créer le profil, vous devez modifier le /etc/security/exec_attr comme suit résultant:

# profiles -p test 'set desc=testing; add cmd=/usr/jdk/instances/jdk1.8.0/bin/java; set privs=basic; end; commit' 
# usermod -P+test root 

modifier manuellement /etc/security/exec_attr et utiliser les éléments suivants pour l'ensemble de l'autorisation minimale pour java d'exécuter sans erreur d'autorisations (antislashs ajoutées pour une meilleure lisibilité et sont autorisés dans le fichier exec_attr):

test:solaris:cmd:::/usr/jdk/instances/jdk1.8.0/bin/java:privs=\ 
{file_read}\:/lib/amd64/libc.so.1,\ 
{file_read}\:/lib/amd64/libcryptoutil.so.1,\ 
{file_read}\:/lib/amd64/libdl.so.1,\ 
{file_read}\:/lib/amd64/libdoor.so.1,\ 
{file_read}\:/lib/amd64/libelf.so.1,\ 
{file_read}\:/lib/amd64/libgen.so.1,\ 
{file_read}\:/lib/amd64/libkstat.so.1,\ 
{file_read}\:/lib/amd64/libm.so.1,\ 
{file_read}\:/lib/amd64/libm.so.2,\ 
{file_read}\:/lib/amd64/libmp.so.2,\ 
{file_read}\:/lib/amd64/libnsl.so.1,\ 
{file_read}\:/lib/amd64/libnvpair.so.1,\ 
{file_read}\:/lib/amd64/libscf.so.1,\ 
{file_read}\:/lib/amd64/libsocket.so.1,\ 
{file_read}\:/lib/amd64/libthread.so.1,\ 
{file_read}\:/lib/amd64/libucrypto.so.1,\ 
{file_read}\:/lib/amd64/libuutil.so.1,\ 
{file_read}\:/lib/amd64/libz.so.1,\ 
{file_read}\:/proc/*,\ 
{file_read}\:/system/volatile/name_service_door,\ 
{file_read}\:/system/volatile/tzsync,\ 
{file_read}\:/tmp,\ 
{file_read}\:/tmp/hsperfdata_root,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/bin/java,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/jre/lib/amd64/jvm.cfg,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/jre/lib/amd64/libjava.so,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/jre/lib/amd64/libverify.so,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/jre/lib/amd64/libzip.so,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/jre/lib/amd64/server/libjvm.so,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/jre/lib/ext,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/jre/lib/ext/meta-index,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/jre/lib/meta-index,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/jre/lib/resources.jar,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/jre/lib/rt.jar,\ 
{file_read}\:/usr/jdk/instances/jdk1.8.0/lib/amd64/jli/libjli.so,\ 
{file_read}\:/usr/lib/amd64/libCrun.so.1,\ 
{file_read}\:/usr/lib/amd64/libdemangle.so.1,\ 
{file_read}\:/usr/lib/amd64/libsched.so.1,\ 
{file_read}\:/usr/lib/amd64/libsmbios.so.1,\ 
{file_read}\:/usr/share/lib/zoneinfo/US/Eastern,\ 
{file_read}\:/vagrant/HelloWorld.class;limitprivs=file_read 

pour produire l'erreur j'ajouté {file_read}\:/absolute/path entrées jusqu'à ce que l'erreur a été générée. J'ai utilisé des fichiers préexistants générés en appelant find /usr/lib -name '*.jar' et en les ajoutant jusqu'à ce qu'il échoue avec EOVERFLOW

Dans mon cas, la liste de fichiers suivante était suffisante. Retrait de l'un d'eux était suffisant pour que cela fonctionne à nouveau.

{file_read}\:/usr/lib/rad/java/authentication.jar,\ 
{file_read}\:/usr/lib/rad/java/authentication_1.jar,\ 
{file_read}\:/usr/lib/rad/java/config.jar,\ 
{file_read}\:/usr/lib/rad/java/config_1.jar,\ 
{file_read}\:/usr/lib/rad/java/container.jar,\ 
{file_read}\:/usr/lib/rad/java/container_1.jar,\ 
{file_read}\:/usr/lib/rad/java/control.jar,\ 
{file_read}\:/usr/lib/rad/java/control_1.jar,\ 
{file_read}\:/usr/lib/rad/java/dlmgr.jar,\ 
{file_read}\:/usr/lib/rad/java/dlmgr_1.jar,\ 
{file_read}\:/usr/lib/rad/java/errors.jar,\ 
{file_read}\:/usr/lib/rad/java/errors_1.jar,\ 
{file_read}\:/usr/lib/rad/java/evscntl.jar,\ 
{file_read}\:/usr/lib/rad/java/evscntl_1.jar,\ 
{file_read}\:/usr/lib/rad/java/files.jar,\ 
{file_read}\:/usr/lib/rad/java/files_1.jar,\ 
{file_read}\:/usr/lib/rad/java/kstat.jar,\ 
{file_read}\:/usr/lib/rad/java/kstat_1.jar,\ 
{file_read}\:/usr/lib/rad/java/modules.jar,\ 
{file_read}\:/usr/lib/rad/java/modules_1.jar,\ 
{file_read}\:/usr/lib/rad/java/network.jar,\ 
{file_read}\:/usr/lib/rad/java/network_1.jar,\ 
{file_read}\:/usr/lib/rad/java/pam.jar,\ 
{file_read}\:/usr/lib/rad/java/pam_1.jar,\ 
{file_read}\:/usr/lib/rad/java/panels.jar,\ 
{file_read}\:/usr/lib/rad/java/panels_1.jar,\ 
{file_read}\:/usr/lib/rad/java/rad.jar,\ 
{file_read}\:/usr/lib/rad/java/smf.jar,\ 
{file_read}\:/usr/lib/rad/java/smf_1.jar,\ 
{file_read}\:/usr/lib/rad/java/smf_old.jar,\ 
{file_read}\:/usr/lib/rad/java/smf_old_1.jar,\ 
{file_read}\:/usr/lib/rad/java/time.jar,\ 
{file_read}\:/usr/lib/rad/java/time_1.jar,\ 
{file_read}\:/usr/lib/rad/java/usermgr.jar,\ 
{file_read}\:/usr/lib/rad/java/usermgr_1.jar,\ 
{file_read}\:/usr/lib/rad/java/zfsmgr.jar,\ 
{file_read}\:/usr/lib/rad/java/zfsmgr_1.jar,\ 
{file_read}\:/usr/lib/rad/java/zonemgr.jar,\ 
{file_read}\:/usr/lib/rad/java/zonemgr_1.jar,\ 
{file_read}\:/usr/lib/rad/java/zonesbridge.jar,\ 
{file_read}\:/usr/lib/rad/java/zonesbridge_1.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/inventory/engines.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/inventory/metricdata.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/inventory/core.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/inventory/scripts.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/inventory/ocmcert.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/oui/jlib/OraPrereq.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/oui/jlib/OraCheckPoint.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/oui/jlib/OraInstallerNet.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/oui/jlib/OraInstaller.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/oui/jlib/share.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/oui/jlib/xmlparserv2.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/lib/OCMRFCreator.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/lib/OpsCenterHarvester.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/lib/emCCR.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/lib/emgcharvester.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/lib/emocmclnt-14.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/lib/emocmclnt.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/lib/emocmcommon.jar,\ 
{file_read}\:/usr/lib/ocm/ccr/lib/emocmdsf.jar 

Assurez-vous que les changements de profil sont réfléchis par l'exécution profiles -l

Est-ce juste deux bogues sous Solaris 11.3? Un dans la commande profiles (qui peut être travaillé autour), et l'autre dans le noyau? (Qui ne peut pas être facilement contourner)

Answer 1

Tout d'abord, pourquoi ne pas utiliser des caractères génériques comme {file_read}\:/usr/lib/rad/java/*? Cela limitera le nombre d'entrées. En outre, avoir autant de fichiers spécifiquement quand nous parlons de {file_read} sera très cher.

Le nombre de règles sont limitées, mais il y a un (sans papier) réglable: xpol_rules_max que vous pouvez définir dans /etc/system en ajoutant la ligne: set xpol_rules_max=100 ou à la volée en utilisant mdb -wk comme suit:

# mdb -wk 
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp zvpsm scsi_vhci zfs sata sd ip hook neti arp usba kssl sockfs lofs random idm cpc crypto fcip fctl nfs ufs logindmux ptm sppp ] 
> xpol_rules_max/x 
xpol_rules_max: 
xpol_rules_max: 64 
> xpol_rules_max/w 100 
xpol_rules_max: 0x64 =  0x100