This is a cryptographically signed message in MIME format. --------------ms803EC7E1E99C21A0ACB73BB6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've been mulling this for a bit, and here's an architectural idea. It's just a brainstorming concept at the moment so don't kill me if you hate it. Here goes: I think that the kernel framework should be as simple and flexible as possible in the unix tradition. IPTables and PAM do a good job of that already and are nicely extensible via modules. We could extend this concept to provide chains for system actions. Chains for CHOWN, BIND_PORT, FILE_OPEN, MOUNT, etc. Various system calls (a lot of them no doubt) would call a routine such as check_acl() which would take an "action type" argument and provide some extra info. Examples: >From open: check_acl(FILE_OPEN, filename, flags) >From malloc: check_acl(MALLOC, size) >From bind: check_acl(BIND_PORT, portnumber, socketfd) The check_acl would then create a message structure containing the action type, arguments and pointers to other interesting and pertinent data such as process owner, parent process or whatever. The message is then sent to a chain with the same name as the action type. MALLOC messages go to the MALLOC chain. If the chain does not exist then it could go to a DEFAULT chain. Conversely there could be a couple of default chains DEFAULT_STRONG with ornery access controls and DEFAULT_WEAK with openish ones. A config file would tell the messages where to go (MALLOC = DEFAULT_WEAK, BIND_PORT = DEFAULT_STRONG). Having a default chain should allow us to group the 25 identical chains into one entity. This could be extended to make any action equivilent to any other. Security LKMs (SLKM) would attach to the chains that they are interested in at a priority level. Higher priority modules go before lower ones. SLKMs would have the option of creating new chains to work with existing actions or create new ones. For example: MALLOC has no chain (it uses DEFAULT_WEAK) so my SLKM makes a MALLOC chain and inserts itself into the new chain at a medium priority. MALLOC requests are automatically routed to the new chain as actions always go first to chains named after them. A SLKM could also create module specific actions such as MAC_CHECK or MOUNT. The actions could be accessed by a system call available to user space. Allowing multiple SLKMs to bind to the various chains we can have modules co-exist with one another whether or not their functionality overlaps. Administrators could, of course, change the order in which modules intercept calls. Since DEFAULT chains exist, the number of chains (and therefore overhead) would be minimized. A log target would also deal nicely with the auditing issues. Another possibility would be to just make the whole thing work like iptables where the chains would be rules not just pointers to modules ala PAM. Many security architectures could be implemented as scripts that load rule sets much like a firewall. Modules could still be written for extended functionality such as Mandatory Access Controls (MAC) with the modules taking care of pesky details such as the security label of a particular system object. I like this system of doing things better than the PAMish way. One last idea... a DEFAULT set of rules and modules could be compiled into the kernel so that the system starts more or less in the shape you want it so that no one has the opportunity to muck around while the system is coming up. Neil P.S. - If this subsystem isn't compiled into the kernel, we just use #IFDEFs to ensure that the old behaviour is followed (but that should be obvious I suppose). - A lock_chains and lock_table call would be useful so they can't be modified. --------------ms803EC7E1E99C21A0ACB73BB6 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 MIIJgwYJKoZIhvcNAQcCoIIJdDCCCXACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BzYwggQAMIIDaaADAgECAhBmIWE+KmYqJrM+NgcOGlAgMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDgyMzAwMDAw MFoXDTAxMDgyMzIzNTk1OVowggEPMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFTATBgNVBAMUDE5laWwgQm9ydG5hazEfMB0GCSqGSIb3 DQEJARYQbmVpbEBib3J0bmFrLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApegn FQ4vPh4YPPDFti/QxNxEbpiJtAw44kmnnIBKusbVvp4A0e7oRqsCO1zkOSQArmI780NwRTxH SSlEUSR4uUdPclKJ7i0sS/MhLbkhV2+RBrVGNZ7SYXsWkK9JdbwTFPa1v8GgAyNuJHdJyCV8 rWHNgOw3jE8vf8tnBZRkFtECAwEAAaOBnDCBmTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHAQgwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YTARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJp c2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAsakwE8dyOFUkhLbaY2SKe Np9RuhLkFfIceV5O0B3PVw6vvHVvXgweSxLr+VR/9g8k6bnJ64WM7v8CIk3/gMNPVc22xOvq VM/6pqqZsNhlG5ciOFUay8krM6Y9I1UdW2UJ6Xbj5NIVapuCKcXTMx3Xbn1QFtRUkb0josgg crDdhjCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3Mg MSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAw MDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/ VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8V eDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vC O7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErI CQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhF AQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8G A1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3 AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrl Cwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhq wY0DPOvDzQWikK5uMYICFTCCAhECAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgw RgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJz b25hIE5vdCBWYWxpZGF0ZWQCEGYhYT4qZiomsz42Bw4aUCAwCQYFKw4DAhoFAKCBijAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTA0MTMwMDMzNDNaMCMG CSqGSIb3DQEJBDEWBBRtFLOFkbAkC9sfsKqrj0wZL1wD6jArBgkqhkiG9w0BCQ8xHjAcMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBgkqhkiG9w0BAQEFAASBgHQzh98QagEo/5P3 vQiTzaJe0468t4/JBgy/tyzNTBr77cyYKPapt6iQhDXkZjf9TLSnPx3ekAjATFFoM4GaH9wv +anbzICgweOs0KbWrH0g7GS7+HzLHHPnmO/CIBYa0Z+IWnoV4zedbDbYMy970Jk03Rhy0y2K QyurL4cckbmO --------------ms803EC7E1E99C21A0ACB73BB6--
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:25 PDT