Determining userland return address (from syscall)

[Rojer]

Steve Watt wrote:
> In article <41D8859E.4080609 at rojer.pp.ru> you write:
> [ snip ]
> 
>>The solution I am about to implement is based on a custom setuid 
>>syscall, that would allow limited list of processes to obtain root 
>>privileges from a limited set of locations (supposedly, the trusted 
>>ones, originating in the httpd's .text section).
> 
> 
> Unfortunately, the extremely powerful mmap() and munmap() system calls
> will allow remapping of text addresses, which kinda blows away your
> whole scheme.

yes, but i could check if the memory region covering the return address
is indeed a shared text segment (e.g. is backed by the file with given inode).
or if it is just the same as that of the parent process.
and to my understanding, while able to remap .text, malicious user would not be
able to remap it read-write from the same file (httpd), as he wouldn't be allowed to
by file permissions.

> 
> 
>>The key point here is ability to trust a call being made from a specific 
>>location. I assume that process cannot change its .text section once 
>>loaded so this scheme would no be abused by overwriting the location 
>>with malicious code. Am I correct here? What do you think of this scheme 
>>overall?
> 
> 
> Probably insufficient.  The safest way is still isolated processes,
> possibly one (or, worse resource-wise, more) per UID, and those
> processes communicate via pipes, unix-domain socket pairs, or similar
> controlled IPC.  The parent vfork()s, does appropriate uid/gid/gidset
> rearrangement, and execs the "user server" process, which would then
> hang around servicing stuff for some time.
> 
> There don't seem to be better alternatives for doing this securely
> and still keep reasonable *NIX-like behavior.
> 
this is no good either... overhead would bring down our servers right away.

-- 
Deomid Ryabkov aka Rojer
myself at rojer.pp.ru
rojer at sysadmins.ru
ICQ: 8025844
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3228 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20050104/99715851/smime.bin