Hi,

Any process can open a file and issue a write system call without any key passed in the call. Its a security issue.

Can I modify write system call as

write( fp, pointer , sizeof data , key) where key has to be passed along with the system call to make sure that the right process is writing the data to the file. The system call implementation checks that only with the right key certain file operations are allowed.

Please comment.


Apart from this idea,
Is there any way in Linux with which we can make sure that right process is writing to a given file. As far as I know this is why we use data basses since an OS can not provide any security to the data at file level.

Thanks for any input,...

You know all about UIDs, capabilities, ACLs and security contexts, right?

Hi,

concept of UID's is OK. But could you please elaborate on the other topics Please.

ACL: access control list.
The commands to work with it: getfacl, setfacl.
Example use: getfacl file; setfacl -m user:rw file;
Man pages: sane.

Access control list allows file owner to determine exactly which users and groups (more exactly, processes owned by which users and groups) have the right to access the file.

Granularity: for actions - same as Unix permissions; for accessed data - per file; for accessing entities - arbitrary sets of users and/or groups.

AFAIK this is already been taken care of: permissions to a file are checked when open(2) is called. The file descriptor returned by open(2) cannot be abused by other processes.

As pointed out by the other posts, ACL's can be used to provide finer grained control of file permissions.

I am sorry if the question is very simple.

So if I have 2 root administrators and one of them can read and write a file which the other root administrator should not be able to write,

I have to
add a user at root level say admin_2 and then set the permissions accordingly for him so that he wont be able to write to the file,
but the first administrator can read and write as root and
though admin_2 is also at root he wont be able to change the acl set by the first admin..

Please comment.

Thanks...

Well, either you want the second administrator to be full root or you want to restrict him somehow. SELinux was proud that they provided some possibilities to have root with UID 0 tied down to guest level. But then you need to learn SELinux.

So, what actual permissions should the less powerful system administrator have?

Hi,

The second admin should not be able to read or write one particular file.Except that he can do all other things that the main admin can do.

Thanks...

Should anyone at all be able to read the file? Maybe let the main administrator keep it on removed medium in a locked box? Because "do anything except reading that file" is not something you can enforce. Being able to upgrade the system means being able to replace any program that can be used for reading the file with a version leaking data..

I think the basic problem is finding a "hook" to tie things to. AFAIK with DAC and ACL you have no hook at all (because UID "just" is 0 and that's all the kernel sees). If you assert that both admins log in as unprivileged user then there must be a transition from unpriv to root (if you don't use Rootsh, Sudo or even su then you've got bigger fish to fry). With SE Linux you could write a policy that restricts access by role (force transition to admin role) but that would AFAIK require a MLS-type of policy which writes everything a role can do which is complex, invasive and probably too hard to get right in one go. Another way to explore could be TOMOYO Linux on top of DAC (applies cleanly to vanilla kernel.org source and can run next to SE Linux w/o *any* problems). TOMOYO in terms of hooks is path-based (not similar to but more similar to AppArmor than SE Linux) and allows you to write rules that allow a domain ("<kernel> /sbin/init /bin/rootsh /bin/noexec /bin/vi") read/write access to files. If the file is not listed and the domain (think process) is put in enforcing mode then read/write should effectively be denied. As far as I can see that would be (relatively) less work than SE Linux MLS but still needs everything covered that could result in read/write access.

It would be good to know what the actual file is and its purpose. If it's not in use by the system then any form of file encryption is way more cost-effective IMNSHO.

hi,

1. I do not want to encrypt the file as number of read operations are more on the file.

2. The file has some important information and will be often read and rarely written by the process of one admin. The other admin should not be able to read or write to this file. Except that he must be able to act like a normal ROOT admin. or root user.

That is, there is a program in root mode which will write to a file but no other PROCESS in the root mode should be able to write to that file.

Is it possible to tie a file to a process

Please guide me further...

No local operation can be safely denied to local root user.

Like Raskin already said: no. In general there is no way to accomplish that. Without costly and invasive changes root is and remains omnipotent.

My guess is that he is trying to build some kind of intrusion detection.

How so? He clearly said "The other admin should not be able to read or write to this file". That's access restriction, isn't it?