Toshiharu Harada
harad****@nttda*****
2007年 7月 22日 (日) 18:28:16 JST
これはさきほど転送したメールに対するStephenからの返事です。 これを受けて、SELinuxに関連する部分をselinux-usersに 送付しています。 今後このスレッドについて、tomoyo-devをccして行うつもりです。 -------- Original Message -------- Subject: Re: [RFC] TOMOYO Linux Date: Fri, 20 Jul 2007 08:25:56 -0400 From: Stephen Smalley <sds****@tycho*****> Organization: National Security Agency To: Toshiharu Harada <harad****@nttda*****> CC: Tetsuo Handa <handa****@pm*****>, taked****@nttda*****, James Morris <jmorr****@namei*****>, Pete Loscocco <pal****@epoch*****>, Karl MacMillan <kmacm****@menta*****> References: <466FA****@nttda*****> <11817****@moss-*****> <46A07****@nttda*****> On Fri, 2007-07-20 at 17:34 +0900, Toshiharu Harada wrote: > Hi, > > Stephen Smalley wrote: > > If you really want feedback or to get your code into the kernel, you > > need to do more than post a URL to the code - you need to break your > > code down into a number of patches and post them, just like the AppArmor > > folks have been doing. I'd suggest further that if you need the same > > support as AppArmor (e.g. passing down the vfsmounts, the improved > > d_path functions, etc), then re-base your patches off of theirs and note > > that yours depend on theirs (aside from their module itself, of course). > > Thanks again for your time and thoughtful suggestions to > TOMOYO Linux. It was a real good experience to talk with you. > (I never expected you to appear my session) Thanks, it was good to meet with you as well. I've cc'd a few other people. > You showed us two options for the future plan. One is > "marriage with AA" and the other is "marriage with SELinux". > > After having a several technical meeting, we are now > aiming TOMOYO Linux as a supplemental MAC for SELinux. > > To do that, we are working on: > i) not to use task_struct security member to > store (TOMOYO) domain information. > ii) adding code to SELinux to call secondary > MAC (that is TOMOYO). I think before we go down the route of implementation details, we should talk first about what functionality you need that SELinux cannot already provide and how to best provide that functionality. And in terms of implementation, our preference would be to extend SELinux and its Flask security architecture and security server as appropriate rather than just trying to stack multiple security modules together. That provides for better integration, well-defined composition, and would allow you to leverage the SELinux data structures as well. Such a discussion could happen via private email, but we would be fine with having it on the public selinux list. We generally prefer public list dialogue to enable open review and feedback as well as archival. > In addition, we added network MAC to LSM version of > TOMOYO Linux. If things go well, we are going to post the result > to the LKML pretty soon according to your advice > to Tetsuo. Ok, that should be interesting, and gives you a leg up on AppArmor in functionality. Please make sure that you have followed the guidance in Documentation/SubmitChecklist, as that will help get your code into a state where more people will be willing to look at it and comment. One of the nice things about another recent LSM that was submitted (Smack) is that it is small and easy to read, which makes it easier to review and comment on. > Stephen, I have a question for you. I remember you told us > SELinux has domain generate/tracking? capabilities like > TOMOYO does. I asked Japanese SELinux users but no > answer was returned. Would you point me the information > resource (papers/url/file anything) on that? It is simply a matter of configuring domain transitions in SELinux using our regular type_transition statements and allow statements (or using the domain_auto_trans macros). Each domain transition in SELinux can be configured based on the caller's domain and the file's executable type, so you can easily express the invocation history in your policy, ala: type_transition local_login_t bash_exec_t:process local_shell_t; type_transition local_shell_t sudo_exec_t:process local_sudo_t; type_transition sshd_t bash_exec_t:process remote_shell_t; type_transition remote_shell_t sudo_exec_t:process remote_sudo_t; Thus, the new domain (local_shell_t vs. remote_shell_t or local_sudo_t vs. remote_sudo_t) tells you the security-relevant aspects of the invocation history. The SELinux decisions are still based on a single domain at a time, but that domain may encode the full (or selective) history. Now, what we don't presently have is a tool that will automatically take audit data and generate such a policy; our existing audit2allow doesn't automatically create new domains. Rather that would require the policy writer (using a tool like SLIDE) to decide where he wants to retain the invocation history and writing his domain transitions accordingly. But one could possibly create an interactive form of audit2allow that asks at each exec whether the user wants to create a new domain and if so, whether the user wants to preserve the invocation history by encoding it in the type name. > I wanted to share my experience of OLS2007 to Japanese > people, so I wrote a Wiki page and introduce it to Japanese > Linux community including SELinux users ml. > The content is only in Japanese (I'm sorry for that), > but there are some pictures. I'll be happy if you > have time to take a look. > > http://tomoyo.sourceforge.jp/wiki/?OLS2007-BOF Ah, nice pictures. Unfortunately, I don't know Japanese myself, so I can't read the content. -- Stephen Smalley National Security Agency -- 原田季栄 (Toshiharu Harada) harad****@nttda*****
TOMOYO
Fork