Re: Problem with accessing namespace_sem from LSM.
On 11/6/2007 1:11 PM, Arjan van de Ven wrote: On Tue, 06 Nov 2007 13:00:41 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: Hello. I found that accessing namespace_sem from security_inode_create() causes lockdep warning when compiled with CONFIG_PROVE_LOCKING=y . sounds like you have an AB-BA deadlock... sed /you/AppArmor shipped with OpenSuSE 10.1 and 10.2/ :) Though I don't think this deadlock should occur quite often, it occurs when it occurs. Care should be taken promptly. There should be no way around for this problem as its nature. Passing vfsmount parameter to VFS helper functions and LSM hooks seems to be a good choice to me. Cheers, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, "waste of time" is taking place here, but it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is "let's make progress and help each other to make Linux better". Thank you, Toshiharu Harada Chris Wright wrote: > * Chris Mason ([EMAIL PROTECTED]) wrote: >> I'm sure people there will have a different versions of events. The >> one part that was discussed was if pathname based security was >> useful, and a number of the people in the room (outside of >> novell) said it was. Now, it could be that nobody wanted to argue >> anymore, since most opinions had come out on one list or another by >> then. > > Indeed. The trouble is that's too high level compared with the actual > implementation details. AA is stalled because it has failed to get > VFS support for it's model. I don't see a nice way out unless it > changes it's notion of policy language (globbing is the tough one) > or gets traction to pass dentry/vfsmount all the way down. Paths are > completely relevant for security, esp. when considering the parent dir > and the leaf (as in forward lookup case). Retroactively creating the > full path is at the minimum ugly, and in the worst case can be insecure > (yes AA has taken many measures to mitigate that insecurity). > >> But as someone who doesn't use either SElinux or AA, I really hope >> we can get past the part of the debate where: >> >> while(1) >> AA) we think we're making users happy with pathname security >> SELINUX) pathname security sucks > > Yes. Please. Both parties are miserably failing the sanity test. > Doing the same thing over and over and expecting different results. > > AA folks: deal with the VFS issues that your patchset have in a palatable > way (which does not include passing NULL when it's inconvenient to > do otherwise). You've already missed an opportunity with Christoph's > suggestions for changes in NFS. I know you've considered many alternative > approaches and consistently hit dead ends. But please note, if you > have coded yourself into a corner because of your policy language, > that's your issue to solve, not ours. > > SELinux folks: do something useful rather than quibbling over the TCSEC > definition of MAC and AA's poor taste in marketing literature. Here's > some suggestions: > > 1) Make SELinux usable (it's *still* the number one complaint). While > this is a bit of a cheap shot, it really is one of the core reasons AA > advocates exist. > 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. > 3) Write an effective exploit against AA that demonstrates the fundamental > weakness of the model (better make sure it's not also an issue for > targetted policy). -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, "waste of time" is taking place here, but it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Well, I crated a Wiki page. If it helps, please feel free to use it. I mean I would like people to add your issues here. It's wiki, so you are welcome to modify everything. http://tomoyo.sourceforge.jp/wiki-e/?MAC-ISSUES If ml is better, I have no objections. I just wanted to help discussion. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is "let's make progress and help each other to make Linux better". Cheers, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/29, Kyle Moffett <[EMAIL PROTECTED]>: >>> But writing policy with labels are somewhat indirect way (I mean, >>> we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we >>> need a lot of work that is what I wanted to tell. >> >> I don't really use "ls -Z" or "ps -Z" when writing SELinux policy; I >> do that only when I actually think I mislabeled files. > > I believe what you wrote, but it may not be as easy for average > Linux users. As I said before, average Linux users should not be writing their own security policy. I have yet to meet an "average Linux user" who could reliably quote for me what the file permissions on the "/tmp" directory should be, or what the sticky bit was. A small percentage of average Linux system administrators don't get that right consistently, and if you don't understand the sticky bit then you should *definitely* not be controlling program permissions on a per- syscall basis. Thank you for your detailed and thoughtful explanation. Things are much clear now for me. Although your explanation was quite persuasive, I still have some concerns. Linux is now being used literately everywhere. As devices, technologies and Linux itself is evolving so quickly, I'm afraid the way you showed was right but could never meet the every goal perfectly. So some areas, including embedded and special distro I guess, there must be solutions and help for average level administrators. I think there are two ways to make secure systems. One is just you wrote: "ask it professionals" way, the other is "making practices". You might ask "how?" My answer to the question is pahtname-based systems such as AppAmor and TOMOYO Linux. They can't be compared to SELinux, but they should be considered to supplemental tools. At least they are helpful to analyze how Linux works. Tweeking SELinux policy is not easy but writing policies for them is relatively easy (I'm not talking about security here). Not everybody can be a professional administrators, but he/she can be a professional administrator of his/her system. I believe there must be solutions for non professional administrators. That's why we developed TOMOYO Linux (http://tomoyo.sourceforge.jp/) and so was AppArmor I guess. You might laugh, but we are doing this because we want to contribute to Linux and its community. :) Thanks, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>: On May 27, 2007, at 03:25:27, Toshiharu Harada wrote: > 2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>: How is that argument not trivially circular? "Foo has an assumption that foo-property is always properly defined and maintained." That could be said about *anything*: What I wanted to mention was the difficulties or efforts to make assumptions real. I never meant a circular argument, but if you felt so I apologize sincerely. >> If you can't properly manage your labels, then how do you expect >> any security at all? > > Please read my message again. I didn't say, "This can never be > achieved". I said, "This can not be easily achieved". So you said "(data labels) can not be easily achieved". My question for you is: How do you manage secure UNIX systems without standard UNIX permission bits? Also: If you have problems with data labels then what makes pathname based labels "easier"? If there is something that could be done to improve SELinux and make it more readily configurable then it should probably be done. Permission bits can be checked easily with "ls" command, but assuring the correctness of labels are not that easy. I'll try to explain. The correctness of the permission bit for a given file can be judged solely by the result of "ls" command. The correctness of the label, on the other hand, can't be judged without understanding of whole policy including domain transitions. (see the attached figure) I can imagine that once one get the complete SELinux policy, then it is able to modify and maintain it. I don't say making a complete SELinux policy is impossible, and actually you said you did it. But to be frank, I don't think you are the average level user at all. ;-) > I'm very interested in how you can know that you have the correct > object labeling (this is my point). Could you tell? I know that I have the correct object labeling because: Do you mind if I add this? 0) I understood the default policy and perfectly understand the every behavior of my system. this is where the difficulties exist. 1) I rewrote/modified the default policy to be extremely strict on the system where I wanted the extra security and hassle. 2) I ensured that the type transitions were in place for almost everything that needed to be done to administer the system. 3) I wrote a file-contexts file and relabeled *once* 4) I loaded the customized policy plus policy for restorecon and relabeled for the last time 5) I reloaded the customized policy without restorecon privileges and without the ability to reload the policy again. 6) I never reboot the system without enforcing mode. 7) If there are unexpected errors or files have incorrect labels, I have to get the security auditor to log in on the affected system and relabel the problematic files manually (rare occurrence which requires excessive amounts of paperwork). Thank you for the procedures. It's quite helpful. > I don't deny DAC at all. If we deny DAC, we can't live with Linux > it's the base. MAC can be used to cover the shortages of DAC and > Linux's simple user model, that's it. > > From security point of view, simplicity is always the virtue and > the way to go. Inode combined label is guaranteed to be a single > at any point time. This is the most noticeable advantage of label- > based security. I would argue that pathname-based security breaks the "simplicity is the best virtue (of a security system)" paradigm, because it attributes multiple potentially-conflicting labels to the same piece Every pathname-based security must provide the mechanism to prevent a conflicting/malicious access, otherwise it's junk. I have a question for you. With current implementation of SELinux, only one label can be assigned. But there are cases that one object can be used in different context, so I think it might help if SELinux would allow objects to have multiple labels. (I'm not talking about conflicts here) What do you think? > But writing policy with labels are somewhat indirect way (I mean, > we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we > need a lot of work that is what I wanted to tell. I don't really use "ls -Z" or "ps -Z" when writing SELinux policy; I do that only when I actually think I mislabeled files. I believe what you wrote, but it may not be as easy for average Linux users. Typically the SELinux-policy-development cycle is: 1) Modify and reload the policy 2) Relabel the affected files (either by hand or with some automated tool like restorecon) 3) Rerun the problem program or daemon 4) Examine the errors in the audit logs. If there are no errors and it works then you're finished. 5) Go back to step 1 and fix your policy Cheers, Toshiharu Harada <>
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>: On May 26, 2007, at 19:08:56, Toshiharu Harada wrote: > 2007/5/27, James Morris <[EMAIL PROTECTED]>: >> On Sat, 26 May 2007, Kyle Moffett wrote: >>> AppArmor). On the other hand, if you actually want to protect >>> the _data_, then tagging the _name_ is flawed; tag the *DATA* >>> instead. >> >> Bingo. >> >> (This is how traditional Unix DAC has always functioned, and is >> what SELinux does: object labeling). > > Object labeling (or labeled security) looks simple and straight > forward way, but it's not. > > (1) Object labeling has a assumption that labels are always > properly defined and maintained. This can not be easily achieved. That's a circular argument, and a fairly trivial one at that. Sorry Kyle, I don't think it's a trivial one. The opposite. If you can't properly manage your labels, then how do you expect any security at all? Please read my message again. I didn't say, "This can never be achieved". I said, "This can not be easily achieved". If you can't manage your "labels", then pathname- based security won't work either. This is analogous to saying "Pathname-based security has an assumption that path-permissions are always properly defined and maintained", which is equally obvious. Yes,! You got the point. Both label-based and pathname-based apporaches have the advantaes and difficluties. In that sense they are equal. That's what I wanted to say. Both approaches can be improved and even can be used combined to overcome the difficulties. Let's not fight against and think together, then we can make Linux better. If you can't achieve the first with reasonable security, then you probably can't achieve the second either. Also, if you can't manage correct object labeling then I'm very interested in how you are maintaining secure Linux systems without standard DAC. I'm very interested in how you can know that you have the correct object labeling (this is my point). Could you tell? I assume your best efforts end up with - have a proper fc definitions and guard them (this can be done) - executes relabeling as needed (best efforts) - hope everything work fine > (2) Also, assigning a label is something like inventing and > assigning a *new* name (label name) to objects which can cause flaws. I don't understand how assigning new attributes to objects "can cause flaws", nor what flaws those might be; could you elaborate further? In particular, I don't see how this is really all that more complicated than defining additional access control in apache .htaccess files. The principle is the same: by stacking multiple independent security-verification mechanisms (Classical UNIX DAC and Apache permissions) you can increase security, albeit at an increased management cost. You might also note that ".htaccess" files are yet another form of successful "label-based" security; the security context for a directory depends on the .htaccess "label" file found within. The *exact* same principles apply to SELinux: you add additional attributes backed by a simple and powerful state- machine. The cross-checks are lower-level than those from .htaccess files, but the principles are the same. I don't deny DAC at all. If we deny DAC, we can't live with Linux it's the base. MAC can be used to cover the shortages of DAC and Linux's simple user model, that's it. From security point of view, simplicity is always the virtue and the way to go. Inode combined label is guaranteed to be a single at any point time. This is the most noticeable advantage of label-based security. But writing policy with labels are somewhat indirect way (I mean, we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we need a lot of work that is what I wanted to tell. Cheers, Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/27, James Morris <[EMAIL PROTECTED]>: On Sat, 26 May 2007, Kyle Moffett wrote: > AppArmor). On the other hand, if you actually want to protect the _data_, > then tagging the _name_ is flawed; tag the *DATA* instead. Bingo. (This is how traditional Unix DAC has always functioned, and is what SELinux does: object labeling). Object labeling (or labeled security) looks simple and straight forward way, but it's not. (1) Object labeling has a assumption that labels are always properly defined and maintained. This can not be easily achieved. (2) Also, assigning a label is something like inventing and assigning a *new* name (label name) to objects which can cause flaws. I'm not saying labeled security or SELinux is wrong. I just wanted to remind that the important part is the "process" not the "result". :-) -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Hi, 2007/5/24, James Morris <[EMAIL PROTECTED]>: I can restate my question and ask why you'd want a security policy like: Subject 'sysadmin' has: read access to /etc/shadow read/write access to /views/sysadmin/etc/shadow where the objects referenced by the paths are identical and visible to the subject along both paths, in keeping with your description of "policy may allow access to some locations but not to others" ? If I understand correctly, the original issue was whether to allow passing vfsmount to the inode_create LSM hook or not. Which is independent from AA or "pathname based MAC", I think. It is proven that Linux can be used without that change, however it is also clear that current LSM cause the ambiguities as AA people has explained. Clearing ambiguities is a obvious gain to Linux and will make benefits for auditing besides "pathname based MAC". So here's my opinion. If anybody can't explain clear reason (or needs) to keep these ambiguities unsolved, we should consider to merge the proposal. Thanks. -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
