I have a linux executable running on my Ubuntu Machine. I want to grant access to a user in order to execute the program, but I don't want this program to be copied.
I was thinking into making a simple crypter app that will decrypt the program at run time an run it from memory.
Is this feasable ?
You can
chmod -r program
The executable will still be runnable, but you cannot copy it.
I just tested that on Ubuntu 14.04 with a downloaded eclipse binary - it worked.
Please note that this will only work for binaries. It will not work for script files that need to be read and interpreted by a shell or interpreter.
It depends hard on the kind of attack a potential user would be able to do which relates typically to the commercial value of a successful attack.
First of all:
If a user have physical access to the storage there is no chance to protect anything from copying. Simply by booting with another OS make all system internal protections baseless. This will be true for the protected program and also all the programs which do some kind of obscure security features like decryption. You can boot a pc from usb or any other media. Forget about something like rights managements supported by the OS.
To hack the mac address on a pc is something that can be done in a few seconds. Load a kernel driver which register a pseudo network card and you will get any fake mac you want. Who will protect the pc for running with modified kernel?
The next is, that any kind of decryption will result in a memory map which hold the executable during runtime of the prog. Any low privileged hacker can get a copy of this memory and can create a application to get this image to run on any other machine.
As you can see on real world licensing models, the only chance is to use additional hardware which is fully secured like crypto usb sticks or other kind of ciphering agents. Another trick can be some kind of online key repository. But all this can not be done by simply implementing some crypto algos.
If you have a product which must be protected against illegal usage, you have to use a commercial protection.
Sorry that I can not see which is your intention from your question. If you only want to keep a simple application with no commercial value on one pc for a "friend" or you have to secure the income of your business :-)
If I'm understanding, you have a user logged in who needs to run program X but not copy program X?
One way, if this is a compiled executable, is to set execute only, but double check your suid_dumpable kernel setting.
If it's a script, or if you have configuration files that go along with it and those need protection, then the /etc/shadow pattern applies: users need to be able to read that file, but not copy it elsewhere for attack. For this pattern, the solution is to use a mediator program. Specifically, the program can temporarily increase its privilege to read the file, but cannot be coerced into providing access to anything in the file beyond what exactly is needed to run.
The accepted answer to this question explains nicely the variety of options. I personally like the sudo approach.
Related
Recently I have been working with an open source simulator called Multi2Sim (M2S). I'm using the simulator to simulate heterogeneous processors to collect data that I'm using with my senior project that is aimed to test thew efficiency of different replacment policies with heterogeneous processors. The program is downloaded from the official site https://www.multi2sim.org.
After following the instruction, I successfully installed and ran the program on my Ubuntu 14.04 from the terminal by calling the "m2s" command. I used it to run the processors with LRU, FIFO, and Random cache replacement policies because they are the only policies M2S provides. The nature of my senior project demands that I use as many replacement policies as I can. I contacted a group of researchers who worked with M2S and were able to implement their own policies to the program. After sending an nice email inquiring about the process of implementing a policy to M2S, they nicely said that they can't tell me since their search is still ongoing.
After snooping around the M2S files that I downloaded before using "make" command, I found where the replacement policies are written in C in a file called "cache.c". I understand the overall mechanism of how the C program works now.
I don't have much knowledge with how
My question is: If I write the replacement policies to the the "cache.c" file, do I need to use the "make" command again in order for me to use them with the m2s command? or can I somehow implement the policies without having to remake the whole program? If I had to remake the program, is there a possible way to make it in a way that I will have the command in the terminal with a different name?
Thank you all in advance.
Yes. The whole point of make is that it will rebuild those parts of the program which need rebuilding (in fact it is designed to rebuild only those parts of the program that require rebuilding).
You might also want to consider putting the program under source control (git is worth learning) so that when you break it (as you inevitably will whilst learning) you can easily revert your mistakes, and see exactly what you changed.
I have been asked to write a program in C which should debug another program in C language and then store the value of each variable of every line,loop or function in a log file.
I have been searching over the internet and I found articles on debugging using gdb.
Can I somehow use GDB in my program for this purpose and then store the values of each variable line by line.
I've got basic knowledge of C/C++ so please reply in simple terms.
Thanks
Debuggers depend on some special capability of the hardware, which must be exposed by the operating system (if any).
The basic idea is that the hardware is configured to transfer control to a debugger stub either after every instruction of the target program, or after certain types of instructions such system calls, or those meeting a hardware breakpoint condition. Typically this would look like an interrupt, supervisor exception, or the like - very platform-specific detail.
As mentioned in comments, on Linux, you use the ptrace functionality of the kernel to interact with the debugger support provided by the hardware and the kernel, abstracting away a lot of the hardware-unique detail and managing the permission issues. Typically you must either be the same user id as the process being debugged, or be the superuser (root). Linux's ptrace also gives you an indirect ability to do to things like access the memory (literally, address space) of the target application, something critical to debugger functionality which you cannot ordinarily do from another user-mode program on a multitasking operating system.
Other operating systems will have different methods. Some embedded targets use debug pods which connect your development machine to the embedded board by a few wires. In other cases, debug capability built into the hardware is managed by a small program running on the target processor, which then talks back over a serial or network port to the full debugger program residing on the development machine.
A program such as GDB can do more than just the basics of setting debug stop conditions, dumping registers, and dumping program instructions. Much of its code deals with annotating what it displays based on debug metadata optionally left behind by compilers, walking back through stack frames, and giving the user powerful tools to configure all of this - and of course it does most of this in a target-independent way, with the target-unique code mostly confined to a few interchangeable directories.
You can indeed "drive" GDB from another program - many, many GUI type debuggers do exactly that, existing as graphical front ends for GDB. However, if you were assigned to write a debugger, doing it that way may or may not by consistent with your assignment.
I'm developing some software for data encryption in C. Here, I just want to ask whether there are any possibilities to make use of some techniques for anti data deletion "without relying much on specific OS API"? If your answer is that it is possible, I would be happy if you can to tell how and give me a lot of explanation. Otherwise, if it is impossible, you can give me the answer "It is impossible" without much explanation.
The reason why I do to ask is that, I anticipate if someday the attacker had already physical access to the machine, the anti-deletion by using dependent OS API will not work (for example, by using a very fast booting OS like Backtrack 5).
On Unix and its variants, the standard system call to remove a file is unlink(). To prevent data deletion, you would have to ensure that every call to that system call, anywhere in any program run by the system, does whatever alternative trickery you want. That is hard to do at the program level; you'd have to provide a modified C library, and you'd still find some people have worked their way around even that (they wrote some assembler, for example). So, you might do it by modifying the behaviour of the unlink() system call in the kernel, but that's hard and non-portable too.
On Windows, the same comment applies to unlink(), but the chances are high that there are a number of other interfaces that also provide a mechanism for deleting a file. The same arguments apply, but you'd have to trap more system calls, etc.
Finally, if you need any further nails in the coffin, the unlink() system call isn't the only way to destroy data. You can open a file and truncate it, and then close it. The file exists, but the data doesn't. You can open a file and modify it; the file exists, but the original data is lost.
So, I think you are in for a difficult time.
You asked in first a comment and then a revision to the question:
[If] the attacker had already physical access to the machine, the anti-deletion by using dependent OS API will not work (for example, by using a very fast booting OS like Backtrack 5).
I responded:
If the attacker can boot to a different OS, the game is over — you can't stop the other OS from deleting the files in your current OS.
Old and ugly the words may be, but they are fundamentally true. The OS is in charge of the raw hardware. If the attacker gets to choose what is in charge of the hardware, the attacker wins.
See also:
The Ten Immutable Laws of Software Security
Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore
Law #4: If you allow a bad guy to upload programs to your website, it's not your website any more
Law #5: Weak passwords trump strong security
Law #6: A computer is only as secure as the administrator is trustworthy
Law #7: Encrypted data is only as secure as the decryption key
Law #8: An out of date virus scanner is only marginally better than no virus scanner at all
Law #9: Absolute anonymity isn't practical, in real life or on the Web
Law #10: Technology is not a panacea
The reason why I do to ask is that, I anticipate if someday the attacker had already physical access to the machine, the anti-deletion by using dependent OS API will not work (for example, by using a very fast booting OS like Backtrack 5).
Sorry, it an attacker can boot a different operating system there's nothing you can do, because any anti-deletion code you may have written won't be running.
This unless you manage to intercept and patch somehow the calls to the ATA/SCSI controller and insert this patch before the BIOS gives control to the OS, but I don't think that's even possible; on the other hand, physical access = root access, the attacker could as well grab a screwdriver, open the case, connect the disk to another computer and do whatever he wants with it.
Sorry, basically IO is operating system. It's the most important operating system's job to provide IO. And the C standard defines so little about it that it's gotta be different, especially when it comes to such an obscure thing as undeleting files.
You might find some library which hides the OS-specific things behind a nice API, but it's still OS dependent on how it performs that action.
First of all, I cannot use a debugger[1]. But I can access the Program Counter of a program, and can also compile the binary (written in C) with all the flags I need. And I can even change the code (although I prefer not to). Given a PC I want to be able to know which line it corresponds.
I'm sure there has to be an automated, practical, quick way to do this. But I haven't succeeded.
Edit: Forgot to mention: Linux system, binaries are PPC, host is i386. I do have access to PPC hardware.
[1] The application is being emulated, and it is cross compiled, I have a gdb in the host emulator. But I cannot connect a gdbserver on the emulated guest application. And real hardware is not an option, I'm trying to build a simulator based on the emulator.
If the binary is compiled with debugging information, then you can use the PC to find the right location in the source by groping through the ELF sections that contain the debug information. Automated, quick and practical aren't the terms that spring to mind for the process, though!
I am wondering if it's possible to write an application that will access a foreign filesystem, but without needing support for that filesystem from the operating system. For example, I'd like to write an app in C that runs on Mac OS X that can browse / copy files from an ext2/ext3 formatted disk. Of course, you'd have to do all the transfers through the application (not through the system using cp or the Finder), but that would be OK for my purpose. Is this possible?
There are user space libraries that allow you to access file systems.
The Linux-NTFS library (libntfs) allows you to access NTFS file systems and there are user space programs like ntfsfix to do things to the file system.
E2fsprogs does the same for ext2, ext3 and ext4 filesystems.
As Basile mentioned, Mtools is another one that provides access to FAT partitions.
There was even a program that does exactly what you're looking for on Windows. It's called ext2explore and allows you to access ext2 partitions from Windows.
It is possible. For example the GNU mtools utility are doing that (assuming a way to access the raw device or partition) for MS-DOS FAT file systems.
However, file systems inside the kernel are usually very well tested and optimized.
Yes and No. For a regular user Application is usually not possible because access to block devices is restricted to root only. Every block device should give read/write to the needed block device for that effect. This would need at best a server/client approach where a service is started on the machine and configured to give the permissions on a per block device manner.
The somewhat easier alternative would be you to use the MacFUSE implementation.
Look here:
http://code.google.com/p/macfuse/
http://groups.google.com/group/macfuse?pli=1
The MacFuse project seems no longer mantained, but can give you a starting point for your project.
The dirty and quick approach is the following as root chmod 666 /dev/diskN
You can hijack syscalls and library calls from your application and then redirect reads/writes to anything like a KV store or a distributed DB layer (using the regular calls for the "virtual devices" that you do not support).
Then, the possibilities are boundless because you don't have to reach the physical/virtual devices when someone asks for them (resolving privilege issues).