streamalism.org

Jeg har lige annonceret det nye Lær foråret kursus med fokus på det grundlæggende i Spring 5 og Spring Boot 2:

1. Oversigt

I denne vejledning ser vi på Java's indbyggede sikkerhedsinfrastruktur, som er deaktiveret som standard. Specifikt vil vi undersøge dens hovedkomponenter, udvidelsespunkter og konfigurationer.

2. SecurityManager i aktion

Det kan være en overraskelse, men Standard SecurityManager indstillinger tillader ikkemange standardoperationer:

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

Her aktiverer vi programmatisk sikkerhedstilsyn med standardindstillinger og forsøger at oprette forbindelse til google.com.

Så får vi følgende undtagelse:

java.security.AccessControlException: adgang nægtet ("java.net.SocketPermission" "www.google.com:80" "forbinde, løse")

Der er mange andre brugssager i standardbiblioteket - for eksempel læsning af systemegenskaber, læsning af miljøvariabler, åbning af en fil, refleksion og ændring af lokalitet, for at nævne nogle få.

3. Brugssag

Denne sikkerhedsinfrastruktur har været tilgængelig siden Java 1.0. Dette var en tid, hvor applets - Java-applikationer indlejret i browseren - var ret almindelige. Det var naturligvis nødvendigt at begrænse deres adgang til systemressourcer.

I dag er applets forældede. Imidlertid, sikkerhedshåndhævelse er stadig et faktisk begreb, når der er en situation, hvor tredjepartskode udføres i et beskyttet miljø.

Overvej for eksempel, at vi har en Tomcat-forekomst, hvor tredjepartsklienter muligvis er vært for deres webapplikationer. Vi ønsker ikke at tillade dem at udføre operationer som System.exit () fordi det vil påvirke andre applikationer og muligvis hele miljøet.

4. Design

4.1. SecurityManager

En af hovedkomponenterne i den indbyggede sikkerhedsinfrastruktur er java.lang SecurityManager. Det har flere checkXxx metoder som checkConnect, der godkendte vores forsøg på at oprette forbindelse til Google i testen ovenfor. Alle delegerede til checkPermission (java.security.Permission) metode.

4.2. Tilladelse

java.sikkerhed. tilladelse tilfælde står for godkendelsesanmodninger. Standard JDK-klasser opretter dem til alle potentielt farlige operationer (som at læse / skrive en fil, åbne en sokkel osv.) Og give dem til SecurityManager for korrekt godkendelse.

4.3. Konfiguration

Vi definerer tilladelser i et specielt politikformat. Disse tilladelser har form af give poster:

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

Det codeBase regel ovenfor er valgfri. Vi kan slet ikke angive noget felt der eller bruge underskrevet af (integreret med tilsvarende certifikater i keystore) eller rektor (java.security.Principal knyttet til den aktuelle tråd via javax.security.auth.Subject). Vi kan bruge enhver kombination af disse regler.

Som standard indlæser JVM den fælles systempolitiske fil placeret på <java.home> /lib/security/java.policy. Hvis vi har defineret en bruger-lokal politik i /.java.politik, JVM føjer det til systempolitikken.

Det er også muligt at specificere politikfil via kommandolinjen: -Djava.security.policy = / min / policy-fil. På den måde kan vi tilføje politikker til det tidligere indlæste system og brugerpolitikker.

Der er en særlig syntaks til erstatning af alle system- og brugerpolitikker (hvis nogen) - dobbelt lig med tegn: -Djava.security.policy == / min / policy-fil

5. Eksempel

Lad os definere en brugerdefineret tilladelse:

offentlig klasse CustomPermission udvider BasicPermission {public CustomPermission (String name) {super (name); } offentlig CustomPermission (strengnavn, strenghandlinger) {super (navn, handlinger); }}

og en delt tjeneste, der skal beskyttes:

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

Hvis vi forsøger at køre det med en sikkerhedsadministrator aktiveret, kastes en undtagelse:

java.security.AccessControlException: adgang nægtet ("com.baeldung.security.manager.CustomPermission" "min-operation") ved java.security.AccessControlContext.checkPermission (AccessControlContext.java:472) ved 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 skabe vores /.java.politik fil med følgende indhold, og prøv at køre programmet igen:

give codeBase "fil:" {tilladelse com.baeldung.security.manager.CustomPermission "min-operation"; };

Det fungerer fint nu.

6. Konklusion

I denne artikel kontrollerede vi, hvordan det indbyggede JDK-sikkerhedssystem er organiseret, og hvordan vi kan udvide det. Selvom målanvendelsestilfældet er relativt sjældent, er det godt at være opmærksom på det.

Som sædvanlig er den komplette kildekode til denne artikel tilgængelig på GitHub.

Jeg har lige annonceret det nye Lær foråret kursus med fokus på det grundlæggende i Spring 5 og Spring Boot 2: