Remkomplekty.ru

IT Новости из мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Java security accesscontrolexception access denied

Amin ‘s Blog

Всякие размышления о жизни, да и так — справочка для себя

пропесочивание Java-приложений

В этой заметке я снова буду нагнетать паранойю, связанную с недостаточно доверенными приложениями. Если вы готовы потратить 10 минут времени на возведение ещё одного рубежа защиты на вашей машине — добро пожаловать. …

Приложений к настоящему моменту создано неимоверно много. Проблема в том, что не существует универсального метода, позволяющего для наугад взятого приложения быстро и достоверно определить наличие уязвимостей или откровенно вредоносных функций. Даже в самом вдоль и поперек изученном продукте могут внезапно найти какую-нибудь уязвимость, которую никто ранее не замечал. Поэтому очень важно стремиться к тому, чтобы даже в случае успешной атаки на приложение полученный вред был минимальным. Одно дело, если через уязвимость в скайпе будет утащен ваш пароль к скайпу, и быть может — лог переписки. Гораздо, гораздо хуже, если полученный доступ также позволит стащить все остальные пароли и ключи доступа.

Именно поэтому я уделяю столько внимания средствам изоляции приложений. И тут как раз нашелся интересный и практичный пример, про который я хочу вам рассказать.
Пример этот — игра Minecraft. Как сервер, так и клиент данной игры написаны на Java. А это значит, что код исполняется внутри отдельной виртуальной машины — Java VM. А следовательно, имеет смысл изучить предоставляемые ею механизмы безопасности, чтобы не городить избыточную паранойю там, где это не требуется.
Ранее я уже писал о виртуальных машинах, SELinux-е и wineprefix-ах. Каждый из них имеет свои особенности и подходящую область применения. Скажем, для сервера мейнкрафта меня вполне устроил уровень изоляции, предоставляемый запуском в SELinux-confined контексте user_*. Далее я буду описывать изоляцию клиентской части игры.
Виртуальные машины отпадают почти сразу. Они прожорливы до памяти, там тяжуло пробрасывать видеокарту, да и подозрительность приложения явно не столь высока, чтобы выделять отдельную ОС под неё. SELinux-sandbox — тоже вещь хорошая, но она требует запуска отдельного Х-сервера, под которым приложения работают не столь отзывчиво. WINEPREFIX неприменим по очевидным причинам (теоретически конечно можно запустить Java-приложение под win32-JRE, запущенной в wine на отдельной префиксе, но это большое извращение, чреватое неожиданными глюками).
Так что надо использовать либо нативные средства изоляции (lxc/unshare/namespaces), либо средства JavaVM. Второе гораздо проще в применении, поэтому на нём и остановимся.

Чуть-чуть теории. В Java есть такая подсистема — Security Manager. Это такая часть JavaVM, которая может подгрузить специальную политику, в которой будет описано, какие вызовы и куда может делать запущенное в данной VM java-приложение. Именно этот механизм используется для защиты основной системы от потенциально вредоносных действий со стороны Java-апплетов, иногда применяемых в веб-интерфейсах и на некоторых сайтах. Браузер всегда запускает апплет с такими ограничениями, и поэтому разработчик апплета вынужден это учитывать.
Разработчики же десктопных Java-приложений, хотя и имеют возможность задействовать этот механизм, писать политику часто ленятся, Security Manager не включают или ставят политику вида «можно всё». Нас это не устраивает, и мы это пофиксим.

Всё, что нам нужно — получить поток ошибок от программы, запустив её с принудительно включенным Security Manager. Но сперва поищем, какие есть готовые Java-политики на нашей системе:

Так, одна политика по-умолчанию, из JRE, вторая — что-то из kde4. Посмотрим их содержимое:

Суть, я думаю, понятна, но можно и дополнительно почитать документацию. Создадим отдельный файл

/.minecraft/_java.policy, где мы будем писать политику доступа для нашего приложения. После чего создаём файл лога ошибок

/.minecraft/errors.log, в одной вкладке консоли запускаем его мониторинг через tail -f, а во второй вкладке заходим в каталог

/.minecraft и запускаем игру вот такой командой (да, домашний каталог для приложения будет немного другой):

После чего отлавливаем в логе сообщения вида java.security.AccessControlException: access denied (« java.util.PropertyPermission » « user.home » « read «) и прописываем для них правила. После нескольких перезапусков и правок файл политики принял вот такой вид:

Заодно спалили, по каким сайтам стучится клиент игры при запуске 😉
После запуска игры с такой политикой kde считает игру апплетом,и у окна рисуется предупреждающий знак. 😀 Самое важное ограничение доступа — к файловой системе — накладывают параметры java.io.FilePermission. Тут мы разрешаем работу только в каталоге мейнкрафта,
все остальные каталоги на файловой системе запрещено даже просматривать.
Параметры вида «permission java.util.PropertyPermission» доступом к файловой системе не управляют, и лишь позволяют программе разрешить прочитать значения соответствующих системных переменных.
Однако считать такую изоляцию глубокой не следует. Например, необходимость разрешения вызова createClassLoader в java.lang.RuntimePermission считается плохой практикой, но без этого клиентская часть не стартует. При более тяжёлой форме паранойи показан к применению SELinux с написанием политик ручками, но конкретно для мейнкрафта достигнутого уровня изоляции, на мой взгляд, достаточно.

Читать еще:  Поле счетчик в access

Недостаток такого метода изоляции в том, что при совершении недопустимого действия, не описанного политикой, программа может выкинуть исключение, и если оно не обработано — то с использованием программы могут возникнуть трудности. Текст исключения выглядит примерно так:

java.security.AccessControlException: access denied

Базовые технологии Java /

Другие технологии

Примеры не работают. Ниже привожу полный код примеров и описание размещения.

Интерфейс Compute и Task

реализация сервера engine

Запуск rmiregistry произвожу следующим образом:
c:Program FilesJavajdk1.6.0_11binrmiregistry.exe

Через TCPView проверяю наличие открытого порта
rmiregistry.exe:3392 TCP iw-d:1099 iw-d:0 LISTENING

Файлы проектов писла в нетбинс 6.8.

Перебросил compute.jar и engine.jar в папку
c:_testsv

Добавил в папку c:_testsv файл server.prolicy

Файл содержит следующий код:

Запуск файла сервера произвожу с помощью пакетного файла start_sv.bat находящегося тамже в c:_testsv

На экран вывод следующее:

Microsoft Windows XP [Версия 5.1.2600]
(С) Корпорация Майкрософт, 1985-2001.

c:_testsv>java -cp c:_testsvserver.policy;c:_testsvengine.jar;c:_test
svcompute.jar -Djava.rmi.server.codebase=file:/c:/_test/sv/compute.jar -Djava.r
mi.server.hostname=localhost -Djava.security.policy=server.policy engine.Compute
Engine
ComputeEngine exception:
java.security.AccessControlException: access denied (java.net.SocketPermission 1
27.0.0.1:1099 connect,resolve)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkConnect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket. (Unknown Source)
at java.net.Socket. (Unknown Source)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(Unknown S
ource)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown S
ource)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source)
at sun.rmi.server.UnicastRef.newCall(Unknown Source)
at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
at engine.ComputeEngine.main(ComputeEngine.java:30)

При этом в TCPView проверяю и вижу строку:
java.exe:3928 TCP iw-d:2708 iw-d:0 LISTENING

Про клиента пока речь не идет — аналогичная ошибка. По искал на форуме — в какой то из тем предлагали добавить в файл политики:

пробовал в приложении оставлять

и запускать rmiregistry.exe 1099 и просто rmiregistry.exe в последнем случае он тоже слушает на порту 1099

запускал РМИРЕГИСТРИ на 1099 порту и в файле политики как раз прописывал — результат не менялся-ошибка прав доступа
permission java.net.SocketPermission «localhost:1099», «connect»;

Как то в начале я неправильно сформировал путь в файле политики — ругался — исправил. Сейчас только эта ошибка -аксесс денайд.

Видимо сервер зарегистрировался
c:_testsv>start_sv.bat

c:_testsv>java -cp c:_testsvengine.jar;c:_testsvcompute.jar -Djava.rmi.
server.codebase=file:/c:/_test/sv/ -Djava.rmi.server.hostname=localhost -Djava.s
ecurity.policy=c:/_test/sv/server.policy engine.ComputeEngine
ComputeEngine bound

хотя среди сетевых соединений я не вижу, чтобы на порту 2707 что либо висело ЖО(

вот как у меня было и етсь на данный момент

причём, если запускаю
rmiregistry.exe 2707

а потом запускаю

java -cp c:_testsvengine.jar;c:_testsvcompute.jar -Djava.rmi.server.codebase=file:/c:/_test/sv/ -Djava.rmi.server.hostname=localhost -Djava.security.policy=c:/_test/sv/server.policy engine.ComputeEngine

получаю следующее
c:_testsv>start_sv.bat

c:_testsv>java -cp c:_testsvengine.jar;c:_testsvcompute.jar -Djava.rmi.
server.codebase=file:/c:/_test/sv/ -Djava.rmi.server.hostname=localhost -Djava.s
ecurity.policy=c:/_test/sv/server.policy engine.ComputeEngine
ComputeEngine exception:
java.rmi.server.ExportException: Port already in use: 2707; nested exception is:

java.net.BindException: Address already in use: JVM_Bind
at sun.rmi.transport.tcp.TCPTransport.listen(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.exportObject(Unknown Source)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(Unknown Source)
at sun.rmi.transport.LiveRef.exportObject(Unknown Source)
at sun.rmi.server.UnicastServerRef.exportObject(Unknown Source)
at sun.rmi.registry.RegistryImpl.setup(Unknown Source)
at sun.rmi.registry.RegistryImpl. (Unknown Source)
at java.rmi.registry.LocateRegistry.createRegistry(Unknown Source)
at engine.ComputeEngine.main(ComputeEngine.java:31)
Caused by: java.net.BindException: Address already in use: JVM_Bind
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(Unknown Source)
at java.net.ServerSocket.bind(Unknown Source)
at java.net.ServerSocket. (Unknown Source)
at java.net.ServerSocket. (Unknown Source)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(Unk
nown Source)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(Unk
nown Source)
at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(Unknown Source)
. 9 more

вобщем то понятно, что программа ищет 2707 порт,который уже занят.
Но, почему же тогда оан не остается висеть сама, когда запускаю ее одну -тобиш серверную часть.

Кто в данном случае будет обрабатывать запросы клиентов.

Java security accesscontrolexception access denied

Hi , I am trying to establish a RMI connection on my local computer. I have created a Server class and generated Skeletons for that through rmic . The jdk version i am using is jdk1.4. When i run the Server class it successfully binds with the default port and localhost. But when i run the client class i get this error message.- java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:1099 .
Please note that i also thought that it could be a certificate issue and hence i copied Server and Client class in the same directory and tried, but still received the same error.
The exception is raise while executing the following line in client.java
registry.lookup(name);
I will appreciate if anyone can help. I am attaching my Server and Client class.

Читать еще:  Ultraiso access violation at address

You probably installed a SecurityManager (that’s «normal» and often flat out necessary in RMI). If you did so, then it looks like you failed to grant your code the necessary permissions.

It’s helpful, when learning this stuff, to create a security configuration that grants «AllPermission» to all code. That way, when you’re learning the mechanics of the system, stuff works. Then, when it’s working, you can / should reduce the permission set to the minimum actually required to work succesfully.

Thanks Simon for your feedback. I have verified that my Server is publishing my interface on the network. I verified it through netstat.

TCP jay-pc:1099 jay-pc.resource.labour.net:0 LISTENING
I have added full path for java.policy like:

and now when i test to see if anything i find anything in registry before lookup i get no value. I am testing it by doing this:

This shows that something is prohibiting my client to get the registry. It could be policy or anything else. I need your help in understanding what else i can try.

Thanks a mil
Jay

I managed to connect and get response from the Server when i kept the Server class and Client class in the same directory. I just checked through netstat that port 1099 was occupied by another process so i
changed the port to 3333 and i could get the response from server by calling my Client.
Now i am testing by keeping my Client and Server in two different projects. But i am getting the below error.

my question is do we have to copy the skelton classes which are generated by rmic to the Client directory?

Thanks Simon, I have been able to get connection. I just changed the java.policy file and granted access to all and it worked.
Now i am facing issues while transferring object over the network. I always get null value from the object at client side. The values are set on the server but when it reaches client it becomes null. Though if i set a string i can easily get that on the client side.
Here are my server and client classes.

This is the Client Class

Objects in RMI can be passed by value, or by reference. Your code looks like you’re trying to have the server modify the object created by the client. For that, you need the client object to be passed by reference. That only happens if you export it as an RMI remote object. If you do that, it doesn’t need to be Serializable. Serializable is use to pass by value, and since you never add the citizen to the array list in the server, then no copy of the modified object will ever get back to the client.

I suggest that pass by value is probably the more robust semantic, since passing references around, while very powerful, does mean you must address any potential concurrency issues.

Hi Simon
Thanks for highlighting that i missed to add the citizen object to the list. I made that mistake while pasting the code into the code section. But actually i am adding citizen object in SaySomething() method.
I just want to achieve a scenario where i pass an object to the server(say in this case citizen ), and the server return that object with Values which can be used on the Client side.
In my example i am passing an empty citizen object to the Server and setting name and surname values to the object and returning it back to the client.
I strongly believe i am making mistake in implementing serialization, the reason being i can receive primitive values like Strings values from server but fail to receive object values.
I want your feedback if i am doing the below things correct:
1. I copied the generated Skelton server classes into my Client directory.
2. I have MyInterface interface on both client side and server side which extends Remote
3. I have Citizen class which implements Serializable,Remote
4. I have the citizen class on both Server and Client side.

Please guide me correcting anything thats not fine here.

If you’re passing objects by value (copying the values and creating a new object on the receiving side) which I believe you are, then the objects in question should not be remote, and should not be exported. They should be Serializable, and nothing else.

Читать еще:  Allow file access from files

If you make something into an exported Remote object, then the stub to it is passed around, and you’re modifying the «server side» (i.e. original) object, not creating a new one and passing it around.

I managed to resolve the issue where i was not able to receive values from my object which was set on the Server side. My object value always used to be null on the Client side.
I was only making one mistake of declaring the variables as static. I removed the static keyword and can pass the objects between Client and Server.
Rest of the things remains as its declared in my previous post.

Java security accesscontrolexception access denied

Привет, любимый читатель.
Сегодня ты узнаешь как подписать JAVA апплет. Для начала скажу, что JAVA апплеты имеют ограниченную функциональность, пока они не подписаны. Например, неподписанные апплеты не могут:

  • взаимодействовать с локальной файловой системой клиента;
  • устанавливать сетевые соединения с другими серверами;
  • взаимодействовать с буфером обмена клиента;
  • некоторые другие.

Вариантов решения проблемы несколько:
1. Разрешить выполнение на каждой локальной машине клиентов. Для этого можно отредактировать файл java.policy, который находится в папке с установленным JRE (по умолчанию в C:Program FilesJavajre6libsecurity). И добавить необходимые разрешения. Например, чтобы разрешить все, что можно, нужно вставить строчку:

А если нужно разрешить только работу с буфером обмена для сайта http://hackmeplease.com:

Этот способ будет удобен только в том случае, если кол-во конечных пользователей твоего сайта ограничено и тебе не в лом на каждом компьютере править этот файл. Кроме того безопасность этого решения не очень высока.

2. Подписать свой Java-апплет. Итак, что имеем на входе:
— установленные JDK и JRE;
— jar-файл своего апплета (есть некоторые особенности написания исходного кода, см. ниже);
— желание работать с буфером обмена. Для этого нужно, чтобы корректно работала строчка:

Toolkit toolkit = Toolkit.getDefaultToolkit();
Clipboard clipboard = toolkit.getSystemClipboard();

В случае вызова этих строчек, из неподписанного апплета получим следующее исключение:
java.security.AccessControlException: access denied (java.awt.AWTPermission accessClipboard)

Итак, приступим:
0. Переходим в папку BIN нашего JDK (например, C:Program FilesJavajdk1.6.0_23bin).
I. Создаем локальное хранилище нашего сертификата (keystore):
keytool -genkey -keystore .keystore -alias «Terrasoft» -validity 99999
где Terrasoft — название alias нашего сертификата;
99999 — срок в месяцах валидности сертификата;
.keystore — имя файла создаваемого хранилища.

В случае успешного запуска команды, система спросит нас пароль нашего хранилища, а также некоторую информацию о сертификате (твои ФИО, название компании, город, страну и группу крови)

В результате будем иметь файл .keystore. Это и есть наше хранилище, которым мы будем подписывать разные апплеты.
II. Копируем в папку BIN нашего JDK наш JAR-файл. Подписываем его с помощью следующей команды:
jarsigner.exe -keystore .keystore ClipboardLibrary.jar «Terrasoft»
где Terrasoft — название alias нашего сертификата;
.keystore — имя файла хранилища;
ClipboardLibrary.jar — название JAR-файла.
Система спросит нас пароль — вводим тот, что ввели в п. I.

Вроде как готово. Да щас, наивный.
Итак, при запуске страницы с нашим апплетом на борту пользователь получит дружественное сообщения вида:

Что означает, «Пользователь, нажми Да и попрощайся со своей системой, ибо мы сможем с ней делать, что захотим».
Кстати, обратите, внимание на NOT VERIFIED. Означает, что у нас не доверительный сертификат. Чтобы получить доверительный, нужно обращаться в специальные службы в инете и даже платить деньгу.

Но вернемся к нашим баранам. При обращении к буферу обмена мы снова получим исключение вида:
java.security.AccessControlException: access denied (java.awt.AWTPermission accessClipboard)

Очень жаль. Ну что же, не получилось сейчас — получится в другой раз. До свидания.

Шучу. На самом деле на этом моменте останавливаются все руководства по подписыванию апплетов, которые я встречал. Мол, подписанному апплету ничего не страшно. Пусть им всем будет стыдно.
Короче, следующий финт для того, чтобы наше обращение к буферу обмена заработало:

III. Изменить исходный код.
Вместо вызова вида:

Вот вобщем то и все. Должно работать. Надеюсь, что кому-то это пригодится, и он не будет столько своей жизни тратить на эту ерунду, сколько потратил я. Нехай проблеми i негоди не роблять Вам в життi погоди (С). До новых встреч в эфире.

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×