|
Hello Stephen, > Subject: Re: type_datum changed from define_type() and type_write() ? > From: sds@xxxxxxxxxxxxx > To: harrytaurus2002@xxxxxxxxxxx > CC: selinux@xxxxxxxxxxxxx > Date: Wed, 23 Feb 2011 09:15:21 -0500 > > On Wed, 2011-02-23 at 08:30 +0000, HarryCiao wrote: > > Hi SELinux experts, > > > > I am trying to add a new rule "typesocket" to checkpolicy which does > > something like "typesocket syslogd_t syslogd_s_t", where syslogd_t is > > the domain for the syslog daemon and the syslogd_s_t would be used to > > label the AF_UNIX socket created by syslog daemon(so that it no longer > > inherits the creator's sid). > > > > I would like to add two extra members in the binary representation for > > the syslogd_t's type_datum structure: a u32 "socket_type_len" field > > before the string of "syslogd_t", and the socket type stri! ng of > > "syslogd_s_t" right after the "syslogd_t" string. > > > > Two new members have been added to the type_datum structure: a char *, > > "socket_type_str" and a uint32_t, "socket_type_len". The newly added > > define_typesocket() in policy_define.c is used to handle this new > > typesocket rule, it will save the string and length of "syslogd_s_t" > > to syslogd_t's type_datum->socket_type_str and socket_type_len fields. > > While the type_write() in libsepol wr! ite.c will try to save > > type_datum->socket_type_str right after the key of the current > > type_datum if type_datum->socket_type_len is not zero. > > > > It seems easy, however, I've run into a strange problem, that the > > type_datum structure used in define_typesocket() during parsing seems > > to be different from the one used by type_write() when writing into > &! gt; binary representations. I put some printfs in these two functions, the > > results are: > > > > /usr/bin/checkpolicy: loading policy configuration from policy.conf > > define_typesocket, syslogd_t.s.value: b09 > > define_typesocket, syslogd_t.socket_type_len: b > > define_typesocket, syslogd_t.socket_type_str: syslogd_s_t > > define_typesocket, syslogd_s_t.s.value: b07 > > /usr/bin/checkpolicy: policy configuration loaded > > /usr/bin/checkpolicy: writing binary representation (version 24) to > > policy.24 > > type_write, key:syslogd_s_t > > s.value: 22d > > type_write, key:syslogd_t > > s.value: ce7 > > socket_type_len: 0socket_type_str: (null) > > > > Where we can see that when "typesocke t syslogd_t syslogd_s_t" is > > parsed, the s.value for the syslogd_t and syslogd_s_t are b09 and b07 > > respectively, and the reference to "syslogd_s_t" has been properly >! ; > setup in syslogd_t's type_datum. However, when writing binary > > representations their s.value have been changed to ce7 and 22d, and > > the reference to "syslogd_s_t" in syslogd_t's type_datum has been > > zeroed. > > > > Any clues?? > > First, I think your approach is wrong - you should declare syslogd_s_t > using a normal type declaration so that it is defined as a discrete > type, and then simply use the existing type_transition statement to > express that you want to label newly created sockets with a type other > than the creator's type. Then you just need to implement the logic in > the kernel to invoke security_transition_sid() when computing socket > labels and you do not need any new language constructs. Many many thanks for your timely reply! Yes, I have declared syslogd_s_t by the type rule then I try to save a referent of syslogd_s_t to the bina! ry representation of syslogd_t's type_datum, in SELinux kernel, the ty pe_read() function will get and save such reference to syslogd_t's type_datum, in the end when a new domain sid is computed I will try to compute the socket SID associated with that domain and make use of it in socket_sockcreate_sid(). Anyway, your suggestion is way much easier and straightforward than mine! I have made simple thing complicated :-P I used to use type_transition rules to specify new labels for regular files, have not realized that types for socket object could be manipulated this way! I've thought about this for a while and quickly implement your suggestion and the relevant kernel logic, I will post them in a separate email for further discussion and review. > > But with regard to your problem, understand that types (and other > symbols) are first assigned temporary values during module compilation, > then they are mapped to their final values during module > linking/expansion into a final policy. So whenever ! you add new state, > you have to preserve it and map it properly during the link/expand > stages. I see, I am a complete checkpoliy/libsepol rookie, don't know much about that. No wonder the type_datum.s.value is different from lexing to the end. Any reference or starting point I could make use of to understand the compile/link/expansion process for the refpolicy? I believe this would be a pretty interesting topic. Thanks again! 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. |
