Jak zmusić Oracle Java 7 do pracy z setcap cap_net_bind_service + ep

11

Usiłuję przyznać plikowi wykonywalnemu Java prawo do otwierania portów poniżej 1024 w systemie Linux. Oto konfiguracja

  • /home/test/java zawiera Oracle Server JRE 7.0.25
  • CentOS 6.4

Oto, co zwraca getcap

[test@centos6 java]$ pwd
/home/test/java

[test@centos6 java]$ getcap bin/java
bin/java = cap_net_bind_service+ep

[test@centos6 java]$ getcap jre/bin/java
jre/bin/java = cap_net_bind_service+ep

Próba wykonania java powoduje następujący błąd. 

[test@centos6 java]$ bin/java
bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
[test@centos6 java]$ jre/bin/java
jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Czy można uruchomić Javę 7_u25, gdy plik binarny ma podwyższone uprawnienia z setcap, jeśli tak, to w jaki sposób?

JDK-6919633: Środowisko wykonawcze nie obsługuje funkcji plików POSIX (AKA Linux Capabilities) mówi, że

Note: when using the setcap the libraries needed by the java launcher
should be present in /usr/lib or any other "trusted" location that the
runtime loader (rtld) uses to find shared libraries.

Jak uczynić biblioteki współdzielone zaufanymi?

linux security java administration setcap ams
źródło

Odpowiedzi:

14

Dopóki nie zadałeś pytania, nigdy nie słyszałem o tej funkcji w Uniksie (możliwości plików). Znalazłem ten link, który wydaje się mieć rozwiązanie, jak sprawić, by ld.so ufał twoim bibliotekom współdzielonym:

fragment tego postu

Gdy ktoś podnosi uprawnienia do pliku wykonywalnego, moduł ładujący (rtld), lepiej znany jako ld.so, nie będzie łączył się z bibliotekami w niezaufanych ścieżkach. Tak właśnie zaprojektowano ld.so (1). Jeśli trzeba uruchomić taki plik wykonywalny, musisz dodać tę ścieżkę do zaufanych ścieżek pliku ld.so, poniżej opisano, jak to zrobić:

Fedora 11:
% uname -a
Linux localhost.localdomain 2.6.29.4-167.fc11.i686.PAE #1 SMP Wed May 27 17:28:22 EDT 2009 i686 i686 i386 GNU/Linux

% sudo setcap cap_net_raw+epi ./jdk1.7.0_04/bin/java

% ./jdk1.7.0_04/bin/java -version
./jdk1.7.0_04/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Jego kaput, Ok jesteśmy teraz na tej samej stronie, aby to naprawić, utwórz plik taki jak> ten, ze ścieżką do libjli.so

% cat /etc/ld.so.conf.d/java.conf
/home/someuser/jdk1.7.0_04/jre/lib/i386/jli

Spowoduje to dodanie nazwy ścieżki do ścieżki zaufanego użytkownika, której będzie używać ld.so, w celu zbudowania pamięci podręcznej środowiska uruchomieniowego, sprawdzenia, czy ld.so widzi to przez to, należy uruchomić ją jako root, i może być konieczne ponowne uruchomienie .

% ldconfig | grep libjli
libjli.so -> libjli.so
.......

Teraz przetestuj Java:

% ./jdk1.7.0_04/bin/java -version
java version "1.7.0_04-ea"
Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b18)

i masz to .....

Bibliografia

slm
źródło
1
To podejście wydaje się być zmianą ogólnosystemową, czy istnieje sposób na ograniczenie zaufania dla poszczególnych użytkowników, aby użytkownik foo i bar mógł mieć swoje własne wersje java z inną wersją libjli.so bez wpadania w konflikt.
AMS
1
@ams: ufasz programowi, który da użytkownikowi możliwości, których zwykle nie mają. Jest to ważne: ufasz kodowi programu, aby nie nadużywać (ani nie dopuszczać do innych nadużyć) tej możliwości. Dlatego musisz ufać tym bibliotekom na poziomie całego systemu.
ninjalj
@ams Możesz użyć narzędzia privbind , aby móc to zrobić dla poszczególnych procesów, a nie dla plików wykonywalnych.
mighq