Date: Tue, 04 Jan 2005 15:55:24 +0300 From: Rojer <myself@rojer.pp.ru> To: Steve Watt <steve@Watt.COM> Cc: freebsd-hackers@freebsd.org Subject: Re: Determining userland return address (from syscall) Message-ID: <41DA923C.8070108@rojer.pp.ru> In-Reply-To: <200501040529.j045T0LV050759@wattres.watt.com> References: <200501040529.j045T0LV050759@wattres.watt.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms030407040606020006020101 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Steve Watt wrote: > In article <41D8859E.4080609@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@rojer.pp.ru rojer@sysadmins.ru ICQ: 8025844 --------------ms030407040606020006020101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIzCC AuwwggJVoAMCAQICAwwKdjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzMxMjIxODA5WhcNMDUwMzMxMjIxODA5 WjBfMRAwDgYDVQQEEwdSeWFia292MQ8wDQYDVQQqEwZEZW9taWQxFzAVBgNVBAMTDkRlb21p ZCBSeWFia292MSEwHwYJKoZIhvcNAQkBFhJteXNlbGZAcm9qZXIucHAucnUwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBxXgFP/1lZDqp0dzUDzR5IBb7aKki6TD+HMMkRjtP IOcaNHsfoDer9RFrFICoxNQZF86iopYFVYr7msgB9y2dKZTRQQoOA72lFrOyH3sgrztx/3LL axEsihA2cxcrglrIgPEm6FF2aabbKVpSdeslMCDPBr0auAm0QLo8ch9c5j0vuQUBrs8TKU6f 6YZLNO2Sk/fPZP2kfJEkXyZhkU6wq3ER1CHq2qgfNpW2Ni7Kuv/eYI/CV1BGgm37ZPubOyxI LNiRUGT0pv0wocrCIehKqoI1uFPZgGS0ANYTqPJQSdjlSzMGQJjT510PNDJnDfKOvLhcadD+ 6gSL/ovNM/LPAgMBAAGjLzAtMB0GA1UdEQQWMBSBEm15c2VsZkByb2plci5wcC5ydTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBACunC6DhFX4I6Nvdy/UevjSd3VmKWPRmqwoR l0RXvuI/JVyPO9KHGqxCMpRu7ArJz7d8ShPVs5kynysrB+Nm6/fwWjeaW21+gViojeO9gGP6 Np/LeMIqkqSYMoElq7Feqh/3qp7a/UxuofFtAW9V/2tRunxaPo4/WOxcdcmdcC86MIIC7DCC AlWgAwIBAgIDDAp2MA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDAzMzEyMjE4MDlaFw0wNTAzMzEyMjE4MDlaMF8x EDAOBgNVBAQTB1J5YWJrb3YxDzANBgNVBCoTBkRlb21pZDEXMBUGA1UEAxMORGVvbWlkIFJ5 YWJrb3YxITAfBgkqhkiG9w0BCQEWEm15c2VsZkByb2plci5wcC5ydTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMHFeAU//WVkOqnR3NQPNHkgFvtoqSLpMP4cwyRGO08g5xo0 ex+gN6v1EWsUgKjE1BkXzqKilgVVivuayAH3LZ0plNFBCg4DvaUWs7IfeyCvO3H/cstrESyK EDZzFyuCWsiA8SboUXZpptspWlJ16yUwIM8GvRq4CbRAujxyH1zmPS+5BQGuzxMpTp/phks0 7ZKT989k/aR8kSRfJmGRTrCrcRHUIeraqB82lbY2Lsq6/95gj8JXUEaCbftk+5s7LEgs2JFQ ZPSm/TChysIh6EqqgjW4U9mAZLQA1hOo8lBJ2OVLMwZAmNPnXQ80MmcN8o68uFxp0P7qBIv+ i80z8s8CAwEAAaMvMC0wHQYDVR0RBBYwFIESbXlzZWxmQHJvamVyLnBwLnJ1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAK6cLoOEVfgjo293L9R6+NJ3dWYpY9GarChGXRFe+ 4j8lXI870ocarEIylG7sCsnPt3xKE9WzmTKfKysH42br9/BaN5pbbX6BWKiN472AY/o2n8t4 wiqSpJgygSWrsV6qH/eqntr9TG6h8W0Bb1X/a1G6fFo+jj9Y7Fx1yZ1wLzowggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwKdjAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAxMDQxMjU1MjRaMCMGCSqGSIb3DQEJ BDEWBBST6Hk9Z45R9fdIi37wOR1yrYeQHTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDDAp2MHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwKdjANBgkqhkiG9w0BAQEFAASCAQAvZC9D zpI6VQCYY+NjR4RBHaP/1kDEymPDSYkcpZ29ba83zQGGBFibl/gbZc0HsKOPGpFm7UhQyjzF 6KXxA/hOY6t+2PcCAf02hnVP8u5BoX2wT8rF4MlTnJSS9xSIanSx5UkZ1MPS+OUxqqQHhuVO +iQV+1LdEXjsmfpFVQtvfSCoRfLBU33oe1HUSgZrY9s+im8945ZOQLzfqsNWEag07IfDJzwV s3GAOqRL5g5MckWzLLRQQloz77y4qSFT1mCu7d9jQDnPiPN25bCXEt0KPtZlABOysNybhk3V 6E8hsPNzkRu7SmI3dfWlAFdq06gGFa9U7Z+Ow1Z5uuO+WlniAAAAAAAA --------------ms030407040606020006020101--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41DA923C.8070108>