Secure Normal User <--> Root Communication

Secure Normal User <--> Root Communication

Post by Michael B Alle » Tue, 08 Jul 2003 03:42:12



Can someone describe a technique for passing information to a root
process by a normal user process but in a way that ensures the root
process can be certain it's from the user that wrote the information? Any
user should be able to write this information but it needs to be tagged
with their uid. For example if a normal user process wanted to execute
a root only function it could write it's uid and parameters to shared
memory and signal the root process to read them and act. However there
would be no way to be ensure that the uid is that of the process that
wrote the parameters. Any ideas?

Thanks,
Mike

 
 
 

Secure Normal User <--> Root Communication

Post by j.. » Tue, 08 Jul 2003 04:20:05



Quote:> Can someone describe a technique for passing information to a root
> process by a normal user process but in a way that ensures the root
> process can be certain it's from the user that wrote the
> information? Any user should be able to write this information but
> it needs to be tagged with their uid. For example if a normal user
> process wanted to execute a root only function it could write it's
> uid and parameters to shared memory and signal the root process to
> read them and act. However there would be no way to be ensure that
> the uid is that of the process that wrote the parameters. Any ideas?

I wouldn't use shared memory for something like this. As you point
out, you can't tell who wrote to it last.

Seems like sudo, or ACLs, would be a better way to approach
this. Have a set of command line programs that can only be run by
specified users/groups, which send the appropriate messages to the
root process.

Joe

 
 
 

Secure Normal User <--> Root Communication

Post by David Schwart » Tue, 08 Jul 2003 07:17:28




Quote:> Can someone describe a technique for passing information to a root
> process by a normal user process but in a way that ensures the root
> process can be certain it's from the user that wrote the information? Any
> user should be able to write this information but it needs to be tagged
> with their uid. For example if a normal user process wanted to execute
> a root only function it could write it's uid and parameters to shared
> memory and signal the root process to read them and act. However there
> would be no way to be ensure that the uid is that of the process that
> wrote the parameters. Any ideas?

    Two ways spring to mind immediately.

    First, a program could write a file to the '/tmp' directory (or another
directory with similar permissions) and pass the filename on to the root
process. The root process could check the owner of the file and make sure it
was writable only by the owner.

    Second, a program could simply launch a setuid root program and pass it
the information (using a pipe or filename). The setuid root program can
verify the origin (by looking at its saved user id) and can communicate
securely with root processes (because it has root permissions itself)
through files in areas writeable only by root.

    DS

 
 
 

Secure Normal User <--> Root Communication

Post by Michael B Alle » Tue, 08 Jul 2003 13:36:21



>> Can someone describe a technique for passing information to a root
>> process by a normal user process but in a way that ensures the root
>> process can be certain it's from the user that wrote the information?

>     First, a program could write a file to the '/tmp' directory (or
>     another
> directory with similar permissions) and pass the filename on to the root
> process. The root process could check the owner of the file and make
> sure it was writable only by the owner.

*Or* as an inverse of that the user process could attach to a writeable
shared memory area of the root process where it just writes it's UID
and notifies the root process which calls seteuid using that uid just to
create an O_RDWR 0600 shared memory area for the user. Then it returns to
being root and signals the user which attaches to it. That is performed
once when the user process initializes.

Now if it want's to communicate information to the root process or perform
a privledged operation it can write it's data to the user process shared
memory area where root can get to it and root knows that only the user
could have written it there. If an impersonator were to write another UID
to root's writeable shared memory, root would create the shared memory
for that user but the impersonator would still not be able to write to it.

Sound feasable?

However a downside to this is that the shared data is strewn all over
the place and the number of users is limited to the number of shared
memory segments the root process can create.

Mike

 
 
 

Secure Normal User <--> Root Communication

Post by David Schwart » Tue, 08 Jul 2003 13:50:57





> *Or* as an inverse of that the user process could attach to a writeable
> shared memory area of the root process where it just writes it's UID
> and notifies the root process which calls seteuid using that uid just to
> create an O_RDWR 0600 shared memory area for the user. Then it returns to
> being root and signals the user which attaches to it. That is performed
> once when the user process initializes.
> Now if it want's to communicate information to the root process or perform
> a privledged operation it can write it's data to the user process shared
> memory area where root can get to it and root knows that only the user
> could have written it there. If an impersonator were to write another UID
> to root's writeable shared memory, root would create the shared memory
> for that user but the impersonator would still not be able to write to it.
> Sound feasable?
> However a downside to this is that the shared data is strewn all over
> the place and the number of users is limited to the number of shared
> memory segments the root process can create.

    Instead of a shared memory segment, it could create a file (also
writeable/readable only by that user and root) and both processes can 'mmap'
it. It will then act like shared memory with the advantage that if the root
process is juggling a large number of clients, it can unmap files it hasn't
used in a while.

    DS

 
 
 

Secure Normal User <--> Root Communication

Post by Gianni Marian » Tue, 08 Jul 2003 16:28:07



> Can someone describe a technique for passing information to a root
> process by a normal user process but in a way that ensures the root
> process can be certain it's from the user that wrote the information? Any
> user should be able to write this information but it needs to be tagged
> with their uid. For example if a normal user process wanted to execute
> a root only function it could write it's uid and parameters to shared
> memory and signal the root process to read them and act. However there
> would be no way to be ensure that the uid is that of the process that
> wrote the parameters. Any ideas?

You could use a technique similar to that of identd.

identd is a identity server for TCP connections.

Another technique is you can do a handshake where the server recieves a
message and then creates a named pipe that can only be opened by the
reported user and send back the name of the pipe or file. You might want
to use sys V shared memory for this so chrooted processes can still
access the resources.

Another way is to use tcp sockets and then interogate which process has
the other end open using /proc/net/tcp on linux.  The drawback is that
this only works on linux but it is certainly quick ...

G

 
 
 

Secure Normal User <--> Root Communication

Post by Michael B Alle » Tue, 08 Jul 2003 16:46:29




>> Can someone describe a technique for passing information to a root
>> process by a normal user process but in a way that ensures the root
>> process can be certain it's from the user that wrote the information?
>> Any user should be able to write this information but it needs to be
>> tagged with their uid. For example if a normal user process wanted to
>> execute a root only function it could write it's uid and parameters to
>> shared memory and signal the root process to read them and act. However
>> there would be no way to be ensure that the uid is that of the process
>> that wrote the parameters. Any ideas?

> Another technique is you can do a handshake where the server recieves a
> message and then creates a named pipe that can only be opened by the
> reported user and send back the name of the pipe or file. You might want

Well I think just writing the UID to the root processes shared memory
and then letting root get the data from that uid's shared memory is
easy enough.

Quote:> to use sys V shared memory for this so chrooted processes can still
> access the resources.

So if I just mmap a file I can't chroot? What if I chroot and *then*
mmap a file?

Mike

 
 
 

Secure Normal User <--> Root Communication

Post by Michael B Alle » Tue, 08 Jul 2003 16:51:32



>> *Or* as an inverse of that the user process could attach to a writeable
>> shared memory area of the root process where it just writes it's UID
>> and notifies the root process which calls seteuid using that uid just
>> to create an O_RDWR 0600 shared memory area for the user. Then it
>> returns to being root and signals the user which attaches to it. That
>> is performed once when the user process initializes.

>> Now if it want's to communicate information to the root process or
>> perform a privledged operation it can write it's data to the user
>> process shared memory area where root can get to it and root knows that
>> only the user could have written it there. If an impersonator were to
>> write another UID to root's writeable shared memory, root would create
>> the shared memory for that user but the impersonator would still not be
>> able to write to it.

>> Sound feasable?

>> However a downside to this is that the shared data is strewn all over
>> the place and the number of users is limited to the number of shared
>> memory segments the root process can create.

>     Instead of a shared memory segment, it could create a file (also
> writeable/readable only by that user and root) and both processes can
> 'mmap' it. It will then act like shared memory with the advantage that
> if the root process is juggling a large number of clients, it can unmap
> files it hasn't used in a while.

So the advantage here is that the file persists on the filesystem which
allows me to get some descriptors back from inactive clients? Otherwise,
what's the difference between shm_open and plain open? Does the VM handle
these pages differently?

I would still have to do the UID negotiation business so that the root
process knows which file (memory) to access the data in right? Or does
your technique suggest a different method?

Mike

 
 
 

Secure Normal User <--> Root Communication

Post by Gianni Marian » Tue, 08 Jul 2003 17:24:36





>>>Can someone describe a technique for passing information to a root
>>>process by a normal user process but in a way that ensures the root
>>>process can be certain it's from the user that wrote the information?
>>>Any user should be able to write this information but it needs to be
>>>tagged with their uid. For example if a normal user process wanted to
>>>execute a root only function it could write it's uid and parameters to
>>>shared memory and signal the root process to read them and act. However
>>>there would be no way to be ensure that the uid is that of the process
>>>that wrote the parameters. Any ideas?

>>Another technique is you can do a handshake where the server recieves a
>>message and then creates a named pipe that can only be opened by the
>>reported user and send back the name of the pipe or file. You might want

> Well I think just writing the UID to the root processes shared memory
> and then letting root get the data from that uid's shared memory is
> easy enough.

I think we've missed too much context here for me to be able to follow
the comment above coherently.  Maybe a bit of pseudo code will help.

Quote:

>>to use sys V shared memory for this so chrooted processes can still
>>access the resources.

> So if I just mmap a file I can't chroot? What if I chroot and *then*
> mmap a file?

file name mapping becomes harder when you chroot, that's all.
 
 
 

Secure Normal User <--> Root Communication

Post by David Schwart » Tue, 08 Jul 2003 19:08:22




Quote:> So the advantage here is that the file persists on the filesystem which
> allows me to get some descriptors back from inactive clients?

    Exactly. Both the client and the server can 'put the file down' and then
'pick it up again'.

Quote:> Otherwise,
> what's the difference between shm_open and plain open? Does the VM handle
> these pages differently?

    Most UNIXes treat them exactly the same, except that pages backed by a
file might get 'synched' to physical media occasionally. Pure shared memory,
on the other hand, would only be written to disk if the system paged. Mny
modern systems will actually page out even when not low on memory (to make
more free memory available for caching) so you might see even less
difference than you'd expect.

Quote:> I would still have to do the UID negotiation business so that the root
> process knows which file (memory) to access the data in right? Or does
> your technique suggest a different method?

    You have any number of options. If the files go in a designated
directory, the root process could simply scan the directory for new files
periodically. Either process could remove the file when it was no longer
needed.

    How much information do you need to communicate? Do you really need/want
shared memory or would a message interface be equally good or better? Also,
are you targetting any specific platforms or are you looking to stay
portable?

    DS

 
 
 

Secure Normal User <--> Root Communication

Post by Juha Laih » Wed, 09 Jul 2003 03:07:00



Quote:>Can someone describe a technique for passing information to a root
>process by a normal user process but in a way that ensures the root
>process can be certain it's from the user that wrote the information?

Would Unix domain sockets be usable here (PF_UNIX/PF_LOCAL)?
It seems that they provide way for the processes to check the
identity of the other end of the connection.
--
Wolf  a.k.a.  Juha Laiho     Espoo, Finland

         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
 
 
 

Secure Normal User <--> Root Communication

Post by Michael B Alle » Wed, 09 Jul 2003 04:58:03



>> I would still have to do the UID negotiation business so that the root
>> process knows which file (memory) to access the data in right? Or does
>> your technique suggest a different method?

>     You have any number of options. If the files go in a designated
> directory, the root process could simply scan the directory for new
> files periodically. Either process could remove the file when it was no
> longer needed.

I think the UID thing would be a little faster though.

Quote:> How much information do you need to communicate? Do you really need/want

I will eventually have a potentially large and complex data structure
with lots of ptrdiff_t's to offsets within the memory of other data
structures ...etc.

Quote:> Also, are you targetting any specific platforms or are you looking to
> stay portable?

POSIX is portable enough for me.

Mike

 
 
 

1. <><><> MOUNTING EXTENDED PARTITION <><><>

I have a 10 GB UDMA IDE drive formatted with Windows.  The first partition
is FAT32, and the second is NTFS.  I can successfully mount the first, but
not the second.  Any ideas?

Suse 7.2 on i86
the drive is mounted on /dev/hdc, and I CAN see hda1, but not hda2

2. how to shrink an image file

3. Wanted: <><><> Unix Specialist <><><>

4. KDE 3.0.1 Knode filters not working

5. LILO help <><><><><><>

6. potential performance impact question

7. sar <interval> <number> doesn't work for non-root user

8. Static version of glibc?

9. rsh <hostname> -n -l <user> <command> hangs on Solaris 8

10. <Alt>+<key> = <Esc><key> ?

11. *{<><>}*Linux*Screen*Difficulties*{<><>}*

12. << <<anyone using dyn-html?>> >>

13. (<><>)*Linux*Screen*Difficulties*(<><>)