I have got a problem with Windows Integrity Mechanism.
I'm using a software called Overwolf
And noticed that one of it's process is running at high integrity level, but not running width admin right.
After some google, still did not get clear.
So, how to run a program with high integrity level but just as a normal user?
Well, I think I get the answer.
First, need to set link flag when build the program, set UAC Bypass UI Protection to :/uiAccess='true', and UAC excution level to: /level='asInvoker'
Second, the program must be signed width a trusted Certification.
At last, the program binary must be placed at system or program file directory.
Related
I am running a Java minecraft server on my Linux server. I have been asked to install some mods (e.g. data packs) on the server which appear to contain Java code written by a third party other than Mojang.
Is this Java code restricted in what it can do, or can it run any arbitrary code it likes (e.g. read /etc/passwd, open TCP ports, claim huge amounts of memory, etc.)?
In other words, how risky are minecraft mods containing Java code?
This is a very good question. I actually was wondering that too. I have spent a bit of time looking at the binaries of minecraft and the minecraft server spigot. I assume we both use the Java Edition.
First of all, the Java code, once you run it on a host, can do anything. The only mechanism that can prevent that and protect the user from the developer in Java, is the security manager. Once you turn on the security manager (which is an opt-in mechanism) you have the ability to define a set of rules that Java will obey like e.g. it will not write into directories you don't allow it too.
So the question is: is minecraft using the security manager per default. I am 99% sure it does not. No one is using the security manager because it is a pain to configure it right and things stop working every time you get it wrong (you know that an applications uses the security manager because you face problems with policy misconfiguration every now and then).
Running minecraft is made by running an exe. I would not now where to turn the security manager on even if I would like too. There is a bit of hope with the spigot server. You can install the security manager with -Djava.security.manager and input your policy with -Djava.security.policy==my.policy. But getting the policy right will be pain. I will try to look into it though when I have a free week or so.
Minecraft mods can act with the full permissions of the user running Minecraft. If you don't trust the author of a mod, then there's basically two approaches to safely use it:
Audit the source code yourself, and then compile the mod yourself so you know it matches the binary
Run Minecraft in a sandbox such as a VM, or as a heavily restricted user.
I am making a Linux application using Python3 and Qt5. When user will install this application, It will create some files in /usr/share folder. To create the files the application needs to have root access.
I plan on having the application show a prompt box to user and user will enter the root password to give root access to the application. But I don't know that how can I give root access to the application by using that password?
This is a world of pain. It's certainly possible to have an application that runs as a normal user carry out certain actions as a privileged user, but I always feel that the need to do this suggests that installation and maintenance hasn't been thought through properly.
To elevate privileges, and assuming the "sudo" isn't appropriate (it probably won't be in this case), you will either need to use an operating system tool that does the job (prompting for credentials and then running something), or implement a helper for your program that has suid attributes on its executable.
I expect all Linux systems have access to "su", but the standard su doesn't have a graphical interface, which is a drag for GUI programs. You can collect the user credentials in your application, and then pass them to su (which is fiddly), or you can use one of the various graphical su-type utilities such as gksu. Of course, that only works if those utilities are available on your platform.
If you go the route of providing your program with a suid part that handles the work that needs elevated privileges, you need to be inordinately careful about security -- how you collect the credentials, how you verify that intruders can't do things they shouldn't, etc.
Frankly, it's a can of worms. I would think that it's nearly always better to provide your application with an installation or maintenance module that has to be run as root. That way all the hard work gets done by the platform.
I am developing an application in Visual C++ 2010, and the application is targeted to Windows 7. There is a task of writing some values to registry that will happen only in some special cases. And since in Windows 7, it is needed to have administrator privileges for doing so. How could I program my application in a way, that when it is needed for doing such actions, it asks for administrator privileges and it would not ask for administrator privileges at start time.
Thanks.
Like Mark said, you cannot elevate your privilege on demand. A quick solution would be to write a separate executable that does the writing part and launch it using specific commandline parameters when you need. Of course this executable would have to have the 'requireAdministrator' privilege in its manifest.
You can also design this program as a service and setup an IPC mechanism, say using a named pipe. The pipe itself could be created with a security descriptor that allows normal user access to it ensuring that the program running at lower privilege will be able to write to it.
The purpose of the second approach is to eliminate the nasty UAC prompt that would appear with the first solution.
I have a UI app (uses GTK) for Linux that requires to be run as root (it reads and writes /dev/sd*).
Instead of requiring the user to open a root shell or use "sudo" manually every time when he launches my app, I wonder if the app can use some OS-provided API to get root permissions. (Note: gtk app's can't use "setuid" mode, so that's not an option here.)
The advantage here would be an easier workflow: The user could, from his default user account, double click my app from the desktop instead of having to open a root terminal and launch it from there.
I ask this because OS X offers exactly this: An app can ask the OS to launch an executable with root permissions - the OS (and not the app) then asks the user to input his credentials, verifies them and then launches the target as desired.
I wonder if there's something similar for Linux (Ubuntu, e.g.)
Clarification:
So, after the hint at PolicyKit I wonder if I can use that to get r/w access to the "/dev/sd..." block devices. I find the documention quite hard to understand, so I thought I'd first ask whether this is possible at all before I spend hours on trying to understand it in vain.
Update:
The app is a remote operated disk repair tool for the unsavvy Linux user, and those Linux noobs won't have much understanding of using sudo or even changing their user's group memberships, especially if their disk just started acting up and they're freaking out. That's why I seek a solution that avoids technicalities like this.
The old way, simple but now being phased out, is GKSu. Here is the discussion on GKSu's future.
The new way is to use PolicyKit. I'm not quite sure how this works but I think you need to launch your app using the pkexec command.
UPDATE:
Looking at the example code on http://hal.freedesktop.org/docs/polkit/polkit-apps.html, it seems that you can use PolicyKit to obtain authorization for certain actions which are described by .policy files in /usr/share/polkit-1/actions. The action for executing a program as another user is org.freedesktop.policykit.exec. I can't seem to find an action for directly accessing block devices, but I have to admit, the PolicyKit documentation breaks my brain too.
So, perhaps the simplest course of action for you is to separate your disk-mangling code that requires privileges into a command-line utility, and run that from your GUI application using g_spawn_[a]sync() with pkexec. That way you wouldn't have to bother with requesting actions and that sort of thing. It's probably bad practice anyway to run your whole GUI application as root.
Another suggestion is to ask the author of PolicyKit (David Zeuthen) directly. Or try posting your question to the gtk-app-devel list.
We have an embedded linux product with an application which lets the user change different settings through the menu system. These settings include IP address/DHCP and time.
We now run this application as root but this feels wrong, letting the user directly interact with a process run as root.
Which user should we use?
If not root, how do we accomplish the permission issues that arise?
EDIT:
The product does not have a graphical user environment in the classical Gnome/KDE fashion. The menu system mentioned is implemented on an LCD panel on the product itself.
If strict controls are applied to input, there is nothing wrong to run an embedded application as root on Linux.
Anyway, when the underlying OS is something like VxWorks, applications run with maximum privileges as well.
I think the question is: what would happen if something goes wrong? I assume the product would just crash and hang or misbehave in any case? The concept of root vs regular user really only applies if there is something that not being root can protect against... which if all you have is a fixed UI does not seem to be the case.
If the application is the main part of the system, then it makes sense to run it as root.
However, even if there is some extra work, it is worthwhile to uncouple your application with your GUI, so your GUI can run with as a normal user.
This can also help you automate your tests.
This assumes that you're running GNOME.
1) Do what the program "Users and Groups" does. It allows you to see the current settings but requires you to unlock the advanced settings such as managing other users.
2) Use gksu extensively.
I would split the code into parts. Create a user for your interface code. You could name it "interface." Then have it call into root via a daemon or sudo to actually execute the changes that require root. Limit the access so that only approved commands can be run.