Hello all, I am a beginner in linux programming. I am working on a type of experimental project in which I need to execute a particular code in a system call only when the system call is called from my program.
I am thinking that a way to do this could be by using pid of the current pointer and then read the commandline attribute from /proc. But I don't know how to use the system calls from within the linux code. Also this method which I am thinking doesn't seem so elegant. Could you please suggest me how to do this or some good method of doing this.

Hi grvsaxena419,

in fact this way is not really elegant as these kind of operations are basically not allowed. How about adding a parameter to your system call. If you pass some value within this parameter from your application the additional code get's executed - otherwise it is simply omitted.

Hope this helps,

Markus

Hello Markus, Thanks for replying.
Actually I am making some changes in the open and unlink system calls so I need to make these calls in their code. I cannot add any parameter in there.

Hi grvsaxena419,

well, a system call is a general entry point for all applications/processes living on top of the operating system. As the system call lives within the linux kernel context there is really no point in distinguishing between different specific calling processes. The system call should not even be aware of the calling process.

So long,
Markus

Hello Markus, yes thats true but I need to implement some functionality based on that, Could you suggest something how can I get the complete process name?

So you're talking about a rootkit? Subverting how a common system call will respond but only to your specific userspace app?
I'd look at how other such kits do it.

1 members found this post helpful.

Hello Proud,
Thanks for replying,
Actually its not a rootkit actually, i am working on securing data from attacks so the system call will respond differently to my userspace app, is that possible? could you suggest some good way of doing that, I am confused in how to specify application in system call code.
Would you be kind enough to tell me some names or provide me some links regarding that.

Can you explain what needs this particular quirk to be more secure, and how it is not security through obscurity?
What do you plan to use to determine the correct process to trust? E.g. a PID? If so, how do you ensure your app is always assigned the same PID if hardcoded, else how will you securely obtain the current PID to trust?

Yes, I am writing a system restore program and i need to protect it from accidental deletion and for this I need to protect it using modified system calls.
I am planning of having a directory eg. /abc which is specific to my application then see if the current process name name of my application then give permissions otherwise don't.
PID would be more difficult I think as I won't be able to fix PID for my application.

Why not just make /abc owned by root or a trusted account, and thus as safe as the rest of your system? If you think this kernel change will stop a rogue "rm -rf /", what about the rest of the userspace that your app depends upon to function? If it depends on nothing else, why not just use a separate cut-down install on a different partition?
Safeguarding your app's directory without ensure the rest of the OS is 'safe' is unlikely to make for a robust system restore mechanism IMHO.

Actually the purpose of my doing this project is to improve my understanding of linux, so I decided to modify kernel to protect the data.
Sorry but could you please explain this a bit, I could not understand.
Ok. I understand that, anyone with root power could install other kernel and delete my data, but I think this will work for most cases.

For security development, you don't just 'think it will work for most cases', you should systematically prove what your system will and will not resist compared to the vanilla version.

How does your application living under /abc perform a system restore? What triggers creation of restore points/states, and the act of restoring?
What do you see as a threat to its integrity that you need to modify those two specific system calls?

I think you understand my point about a rogue "rm -rf /". I'd expect there's little point to allowing root or any other trusted accounts to make arbitrary changes to any other key parts of the OS install but only prevent them from changing your /abc unless they use the executables found within. An accidental or malicious delete-all or reconfiguring/replacement of key system binaries & things like password files is likely to leave your tool unable to truely restore the system's state from a simple userland command, you would need truly read-only checksums & binaries to be sure you weren't being lied to by another subverted system call (which is why I believe most similar mechanisms are found on read-only live discs and other such trustworthy media/host systems.).

Understand I'm only trying to help & encourage your understanding of Linux and this kernel development, I just feel it's key that you look at the big picture as well as the details if you wish to invest your time in producing something that would be useful in the real world.

1 members found this post helpful.

Proud, Thank you very much for sparing your precious time for guiding me, I am a beginner in kernel programming so not know so much about these things.

My system will prevent accidental damage to system, even if rm -rf / destroys other files it cannot delete my program files, and thus the system can be restored again , using a live cd.

The creation of restore points and restore is completely on user wish presently, if user thinks a restore is needed he can do it using the commands. I see accidental deletion , a malicious user as a threat to my data which I think could be prevented by this modification.

Ok I understand your point, could you explain a bit more about read-only checksums & binaries ? How can I have read-only disks, if i use optical medium it would be difficult to make changes in the backup itself. Can I have a partition marked as read-only or with password protected mount ?
How to determine my backup is trustworthy I could keep a md5 hash of files.
Yes I know you are far more experienced and intelligent than me, so you would provide me with much better guidance, yes I will try my best to look at big picture as well.

I don't know why you'd assume I'm more experienced or intelligent, I'm just raising what seem to be the key considerations.

As for updating a read-only medium, I'd look to differential/delta snapshots, perhaps similar to how UnionFS allows trial users of Linux LiveCDs to seamlessly write to locations that appear to be a part of the disc image but end up being stored on a harddrive.

The use of checksums is reasonable, but they're just data, technically you need to still be able to rationally trust that the OS and checksum tool binary are not also subverted. This may sound paranoid, but if you plan for your system to work against malicious activity or even just subtle memory corruption without filesystem-based checksums(such as ZFS) and ECC, you need to bootstrap your new restored system from the bare minimum to build a chain of trust.
For a related read, see this breakdown of the classic example.

I would think that if you take the malicious aspect out of the equation, you could produce a simple enough system to snapshot and/or checksum a whole system. The thing is, what do you expect the source of the need to restore to be? If it's a hardware issue such as failing storage or memory, you will perhaps need the user to use additional tools such as memcheck86+ to determine such things, or to add/replace the storage device with a blank new one while your /abc may now be on the unreliable one.
Also hardware issues are more typically handled by things like RAID now, and filesystems that have built-in transparent integrity checking (again ZFS is a common example but not the only contender). A manually invoked restore system with a dedicate single location of its tools, data and perhaps snapshots seems to require a not-insignificant tradeoff in the end user's time to ensure it is current enough to be of benefit.
Are you familiar with version control tools such as subversion and git, where versions are a state of the whole repository rather than per path/filename?

AFAIK it's best practice for people to separately back up their important data as frequently and granularly as required, and to keep their OS image with current configuration settings to hand should they need to rebuild the setup from scratch. I understand Windows has a system restore mechanism, but I think the unix tradition is to checksum your existing system if you suspect a specific transient integrity problem, perhaps use the package management tools to repair applications, or just start again from a fresh trusted OS image + data backups in the worst case.

Commercially, I am unaware of the supply & demand of such mechanisms.

2 members found this post helpful.

I don't know a great deal about SElinux, but I think it has some capacity to distinguish what applications can/cannot read/write specified files and directories. Perhaps it is worth looking at as a ready-made solution.
--- rod.