|
Hello Stephen, > Subject: Re: Separate socket SID than its creator > From: sds@xxxxxxxxxxxxx > To: harrytaurus2002@xxxxxxxxxxx > CC: jmorris@xxxxxxxxx; eparis@xxxxxxxxxxxxxx; selinux@xxxxxxxxxxxxx > Date: Mon, 28 Feb 2011 08:52:38 -0500 > > On Sun, 2011-02-27 at 10:14 +0000, HarryCiao wrote: > > Hello Stephen, James and Eric, > > > > The attached is the v1 patches to compute socket SID on creation. > > > > The propagation of the return code of security_transition_sid is a > > good practice and actually helps identifying the problem that the > > socket creator's role also needs to be able to type the socket role. > > > > The class number(orig_tclass) used by SELinux kernel driver is checked > > against SECCLASS_XXX macros and if it's any one of those 22 socket > > classes both security_compute_sid and mls_comput_sid will preser! ve the > > scontext's role and MLS attribute as what they have been done for > > policydb.policy_class. (we are not checking access vectors so we don't > > have to concern about the unmapped, real class number allocated by > > checkpolicy) > > > > I've also come up with a debug patch to make use of the > > security_sid_to_context which helps to reveal that the > > unix_dgram_socket object created by syslogd differs only in type from > > its creator and shares the same user, role and MLS at! tribute. The > > relevant changes to logging.pp used for debugging is also attached. > > > > Please kindly help commenting and suggesting how I could further test > > these two patches. > > Kernel patches need to be posted one patch per message, inline, as per > SubmittingPatches. http://userweb.kernel.org/~akpm/stuff/tpp.txt is > also a good re! source on preparing kernel patches. > Ok, I will try to send patches to selinux mailing list by git-send-emails with one patch per message inline. > The order of your patches needs to be reversed so that there is no > change in behavior and everything still works after each patch is > applied - this is important for git bisect. Understand, will do. > > I'm a bit concerned about the maintainability of the socket class list > in security_is_socket_class(). We need to do something to ensure that > if someone later adds a new socket security class to the kernel, they > know to update this list. At least a comment in classmap.h; ideally > some kind of compile-time check (similar to the #error case in hooks.c > to catch when someone adds more than 64 capabilities) to detect when > someone adds a socket class without updating the list there. Or maybe > security_is_socket_class() needs to be auto-generated from classmap.h by > genheaders? ! > Good idea! Actually it won't take much effort to have the genheaders auto-generate the security_is_socket_class() function by traversing the secclass_map[] array and collecting all socket classes' name into the 'case' branch. I will send it out in v2 patches. > Since you are checking against the kernel values rather than the policy > values, you need to make sure you only apply this check when called from > the kernel (if kern == true). > Yeah, since the security_is_socket_class() function checks class kernel value against SECCLASS_XXX macros we should also mapping the class policy value to the relevant kernel value when the security_compue_sid() is called with kern == false, say by compute_create program, which should compute the same SID for socket as in kernel. For this purpose the index for an current_mapping[] entry should be returned if its value is the same as the class policy value. Thanks! ! Best regards, Harry > -- > Stephen Smalley > National Security Agency > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with > the words "unsubscribe selinux" without quotes as the message. |
