streamalism.org

Jeg kunngjorde nettopp det nye Lær våren kurs, med fokus på det grunnleggende i vår 5 og vårstøvel 2:

1. Oversikt

I denne opplæringen vil vi se på Java sin innebygde sikkerhetsinfrastruktur, som er deaktivert som standard. Spesielt vil vi undersøke hovedkomponentene, utvidelsespunktene og konfigurasjonene.

2. Sikkerhetssjef i aksjon

Det kan være en overraskelse, men misligholde Sikkerhetssjef innstillingene ikke tillatermange standardoperasjoner:

System.setSecurityManager (ny SecurityManager ()); ny URL ("// www.google.com"). openConnection (). connect ();

Her aktiverer vi programmatisk sikkerhetstilsyn med standardinnstillinger og prøver å koble til google.com.

Da får vi følgende unntak:

java.security.AccessControlException: tilgang nektet ("java.net.SocketPermission" "www.google.com:80" "koble til, løse")

Det er mange andre brukstilfeller i standardbiblioteket - for eksempel lese systemegenskaper, lese miljøvariabler, åpne en fil, refleksjon og endre lokalitet, for å nevne noen.

3. Use-Case

Denne sikkerhetsinfrastrukturen har vært tilgjengelig siden Java 1.0. Dette var en tid der applets - Java-applikasjoner innebygd i nettleseren - var ganske vanlige. Naturligvis var det nødvendig å begrense deres tilgang til systemressurser.

I dag er applets foreldet. Derimot, sikkerhetshåndhevelse er fortsatt et faktisk konsept når det er en situasjon der tredjepartskode kjøres i et beskyttet miljø.

Tenk for eksempel at vi har en Tomcat-forekomst der tredjepartsklienter kan være vert for webapplikasjonene sine. Vi ønsker ikke å tillate dem å utføre operasjoner som System.exit () fordi det vil påvirke andre applikasjoner og muligens hele miljøet.

4. Design

4.1. Sikkerhetssjef

En av hovedkomponentene i den innebygde sikkerhetsinfrastrukturen er java.lang SecurityManager. Den har flere sjekkXxx metoder som checkConnect, som godkjente vårt forsøk på å koble til Google i testen ovenfor. Alle delegatene til checkPermission (java.security.Permission) metode.

4.2. Tillatelse

java.sikkerhet. tillatelse forekomster står for autorisasjonsforespørsler. Standard JDK-klasser oppretter dem for alle potensielt farlige operasjoner (som å lese / skrive en fil, åpne en stikkontakt osv.) Og overføre dem til Sikkerhetssjef for riktig autorisasjon.

4.3. Konfigurasjon

Vi definerer tillatelser i et spesielt policyformat. Disse tillatelsene har form av stipend innganger:

gi codeBase "fil: $ {{java.ext.dirs}} / *" {tillatelse java.security.AllPermission; };

De codeBase regelen ovenfor er valgfri. Vi kan ikke spesifisere noe felt der eller bruke signert av (integrert med tilsvarende sertifikater i nøkkelbutikken) eller rektor (java.sikkerhet. rektor festet til gjeldende tråd via javax.security.auth.Subject). Vi kan bruke en hvilken som helst kombinasjon av disse reglene.

Som standard laster JVM den vanlige systempolicyfilen på <java.home> /lib/security/java.policy. Hvis vi har definert en brukerlokal policy i /.java.politikk, legger JVM den til systempolitikken.

Det er også mulig å spesifisere policyfil via kommandolinjen: -Djava.security.policy = / min / policy-fil. På den måten kan vi legge til policyer til tidligere lastede system- og brukerpolicyer.

Det er en spesiell syntaks for å erstatte alle system- og brukerpolitikker (hvis noen) - dobbelt likhetstegn: -Djava.security.policy == / min / policy-fil

5. Eksempel

La oss definere en tilpasset tillatelse:

offentlig klasse CustomPermission utvider BasicPermission {offentlig CustomPermission (strengnavn) {super (navn); } offentlig CustomPermission (strengnavn, strenghandlinger) {super (navn, handlinger); }}

og en delt tjeneste som skal beskyttes:

public class Service {public static final String OPERATION = "my-operation"; offentlig ugyldig drift () {SecurityManager securityManager = System.getSecurityManager (); hvis (securityManager! = null) {securityManager.checkPermission (ny CustomPermission (OPERATION)); } System.out.println ("Operasjonen utføres"); }}

Hvis vi prøver å kjøre den med en sikkerhetsleder aktivert, kastes et unntak:

java.security.AccessControlException: tilgang nektet ("com.baeldung.security.manager.CustomPermission" "min-operasjon") på java.security.AccessControlContext.checkPermission (AccessControlContext.java:472) på java.security.AccessController. AccessController.java:884) på ​​java.lang.SecurityManager.checkPermission (SecurityManager.java:549) på com.baeldung.security.manager.Service.operation (Service.java:10)

Vi kan skape vårt /.java.politikk fil med følgende innhold, og prøv å kjøre programmet på nytt:

grant codeBase "file:" {tillatelse com.baeldung.security.manager.CustomPermission "min-operasjon"; };

Det fungerer helt fint nå.

6. Konklusjon

I denne artikkelen sjekket vi hvordan det innebygde JDK-sikkerhetssystemet er organisert og hvordan vi kan utvide det. Selv om målbruken er relativt sjelden, er det godt å være klar over det.

Som vanlig er den komplette kildekoden for denne artikkelen tilgjengelig på GitHub.

Jeg kunngjorde nettopp det nye Lær våren kurs, med fokus på det grunnleggende i vår 5 og vårstøvel 2: