Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On Mon, 28 May 2007 21:54:46 EDT, Kyle Moffett said: Average users are not supposed to be writing security policy. To be honest, even average-level system administrators should not be writing security policy. It's OK for such sysadmins to tweak existing policy to give access to additional web-docs or such, but only expert sysadmin/developers or security professionals should be writing security policy. It's just too damn easy to get completely wrong. The single biggest challenge in computer security at the present time is how to build *and deploy* servers that stay reasonably secure even when run by the average wave-a-dead-chicken sysadmin, and desktop-class boxes that can survive the best attempts of Joe Sixpack's Ooh shiny reflex, and Joe's kid's attempts to evade the nannyware that Joe had somebody install. (If you know how to build such things, don't bother replying. If you have actual field experience on getting significant percents of Joe Sixpacks to switch, I need to buy you a beer or something.. ;) pgp2xhvoFOnBw.pgp Description: PGP signature
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
[EMAIL PROTECTED] wrote: On Mon, 28 May 2007 21:54:46 EDT, Kyle Moffett said: Average users are not supposed to be writing security policy. To be honest, even average-level system administrators should not be writing security policy. That explains so much! SELinux: you're too dumb to use it, so just keep your hands in your pockets. :-) AppArmor was designed to allow your average sys admin to write a security policy. It makes different design choices than SELinux to achieve that goal. As a result, AppArmor is an utter failure when compared to SELinux's goals, and SELinux in turn is an utter failure when compared to AppArmor's goals. Which is why we have LSM: so we don't have to have this argument here, again. It's OK for such sysadmins to tweak existing policy to give access to additional web-docs or such, but only expert sysadmin/developers or security professionals should be writing security policy. It's just too damn easy to get completely wrong. The single biggest challenge in computer security at the present time is how to build *and deploy* servers that stay reasonably secure even when run by the average wave-a-dead-chicken sysadmin, and desktop-class boxes that can survive the best attempts of Joe Sixpack's Ooh shiny reflex, and Joe's kid's attempts to evade the nannyware that Joe had somebody install. That is a tall order. You can mostly achieve it by not giving the user the root password, but I'm not sure you would like the result :-) Both SELinux and AppArmor can be configured so tightly that you are not going to get to install malware, by preventing the user from installing software. This isn't what users want, so they invariably bypass security and install shiny things if they own the box. SELinux and AppArmor can't help but fail if you put them in that kind of harm's way. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - 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 attachment: fig.png
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Hi! That's a circular argument, and a fairly trivial one at that. If you can't properly manage your labels, then how do you expect any security at all? Unfortunately, it's not at all as simple as all that. Toshiharu is quite correct that it isn't always easy to actually implement. Consider how many ad-croc usages of 'restorecon' are needed to get a Fedora SELinux box through rc.sysinit: While I don't think restorecon is really necessary to properly boot SELinux-enabled (I've got a Debian box with some heavily customized policy which does so just fine), I am of the opinion that adding a name parameter to the file/directory create actions would be useful. For example, with such support you could actually specify a type-transition rule conditional on a specific name or substring: named_type_transition sshd_t tmp_t:sock_file prefix ssh- ssh_sock_t; Useful options for matching would be prefix, suffix, substr (start,len). regex would be nice but is sorta computationally intensive and would be likely to cause more problems than it solves. Could someone implement this? AFAICT that prevents SELinux from being superset of AppArmor... Doing this should be significantly simpler than whole AA, and hopefully it will end up less ugly, too. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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
On May 28, 2007, at 06:41:11, Toshiharu Harada wrote: 2007/5/27, Kyle Moffett [EMAIL PROTECTED]: 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. That's why there are a number of efforts to make modular SELinux policies. A good SELinux policy provides a few core system types and labels which a policy developer needs to understand, as well as some good macros to simplify the human-editable policy files. For instance, in my customized policy a daemon run by an initscript which reads a single config file in /etc needs this policy (Note that I use _d as a suffix for process domains instead of the usual _t): initrc_daemon(foo_exec_t, foo_d) daemon_config(foo_d, foo_conf_t) Add maybe 2 lines for network port access, another 2 for database files in /var, plus maybe an iptables rule or two in your firewall file. 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. ;-) Average users are not supposed to be writing security policy. To be honest, even average-level system administrators should not be writing security policy. It's OK for such sysadmins to tweak existing policy to give access to additional web-docs or such, but only expert sysadmin/developers or security professionals should be writing security policy. It's just too damn easy to get completely wrong. 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. You don't have to understand the entire default policy; that's the point of modular policy. You only have to understand how to _use_ the interfaces of the system policy (which are documented) and how the particular daemon policy is supposed to work. The people developing the core system policy need to understand the inner workings of said policy, but they don't need to understand how the rest of the system works. The core functionality behind this separation is macro interfaces and attributes. By grouping types with attributes it is possible for arbitrary daemon types to categorize themselves under access rules defined by the base policy, and with interfaces the daemons don't really even need to know what those attributes are called. 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 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? This is the whole advantage of SELinux type attributes: you can define a type var_foo_t which has a specific list of attributes; rules which accept type specifiers can also accept attribute specifiers as well. If what you want is a label which may be accessed in two different ways, then you declare attributes for each access method and declare a type which has the attributes filetype, access1, and access2 (assuming access1 and access2 are
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On May 28, 2007, at 16:38:38, Pavel Machek wrote: Kyle Moffett wrote: I am of the opinion that adding a name parameter to the file/ directory create actions would be useful. For example, with such support you could actually specify a type-transition rule conditional on a specific name or substring: named_type_transition sshd_t tmp_t:sock_file prefix ssh- ssh_sock_t; Useful options for matching would be prefix, suffix, substr (start,len). regex would be nice but is sorta computationally intensive and would be likely to cause more problems than it solves. Could someone implement this? AFAICT that prevents SELinux from being superset of AppArmor... Doing this should be significantly simpler than whole AA, and hopefully it will end up less ugly, too. Really it would need to extend all action-match items with new named_ equivalents, and most callbacks would need to be extended to pass in an object name, if available. On the other hand, with such support implemented then the AppArmor policy compilation tools could be transformed into a simple SELinux policy generator. I estimate that the number of new lines of kernel code for such a modified SELinux would be 100x less than the kernel code in AppArmor. Cheers, Kyle Moffett - 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
On the other hand, if you actually want to protect the _data_, then tagging the _name_ is flawed; tag the *DATA* instead. Would it make sense to label the data (resource) with a list of paths (names) that can be used to access it? Therefore the data would be protected against being accessed via alternative arbitrary names. This may be a simple label to maintain and (possibly to) enforce, allowing path based confinement to protect a resource. This may allow for the benefits of pathname based confinement while avoiding some of its problems. Obviously this would not protect against a pathname pointing to arbitrary data… Just a thought. Z. Cliffe Schreuders. - 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
CC trimmed to remove a few poor overloaded inboxes from this tangent. On May 27, 2007, at 04:34:10, Cliffe wrote: Kyle wrote: On the other hand, if you actually want to protect the _data_, then tagging the _name_ is flawed; tag the *DATA* instead. Would it make sense to label the data (resource) with a list of paths (names) that can be used to access it? Therefore the data would be protected against being accessed via alternative arbitrary names. This may be a simple label to maintain and (possibly to) enforce, allowing path based confinement to protect a resource. This may allow for the benefits of pathname based confinement while avoiding some of its problems. The primary problem with that is that mv somefile otherfile must change the labels, which means that every process that issues a rename () syscall needs to have special handling of labels. The other problem is that many of the features and capabilities of SELinux get left by the wayside. On an SELinux system 90% of the programs don't need to be modified to understand labels, since the policy can define automatic label transitions. SELinux also allows you to have conditional label privileges based on boolean variables, something that cannot be done if the privileges themselves are stored in the filesystem. Finally, such an approach does not allow you to differentiate between programs. Cheers, Kyle Moffett - 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
On May 27, 2007, at 03:25:27, Toshiharu Harada wrote: 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. 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*: * Unix permissions have an assumption that mode bits are always properly defined and maintained * Apache .htaccess security has an assumtion that .htaccess files are always properly defined and maintained. * Functional email communication has an assumption that the email servers are always properly defined and maintained 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. 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 know that I have the correct object labeling because: 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). (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. 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 of data. It also cannot protect the secrecy of specific *data* as well as SELinux can. For example:
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
--- Cliffe [EMAIL PROTECTED] wrote: On the other hand, if you actually want to protect the _data_, then tagging the _name_ is flawed; tag the *DATA* instead. Would it make sense to label the data (resource) with a list of paths (names) that can be used to access it? Program Access Lists (PALs) were* a feature of UNICOS. PALs could contain not only the list of programs that could use them, but what attributes the processes required as well. Further, you could restrict or raise privilege based on the uid, gid, MAC label, and privilege state of the process during exec based on the PAL. Therefore the data would be protected against being accessed via alternative arbitrary names. This may be a simple label to maintain and (possibly to) enforce, allowing path based confinement to protect a resource. This may allow for the benefits of pathname based confinement while avoiding some of its problems. Yep, but you still have the label based system issues, the classic case being the text editor that uses creat new, unlink old, rename new to old. When the labeling scheme is more sopisticated than object gets label of subject label management becomes a major issue. Obviously this would not protect against a pathname pointing to arbitrary data Protecting special data is easy. Protecting arbitrary data is the problem. Just a thought. Not a bad one, and it would be an easy and fun LSM to create. If I were teaching a Linux kernel programming course I would consider it for a class project. - * I have used the past tense here in spite of the many instances of UNICOS still in operation. I don't believe that there is any current development on UNICOS. Casey Schaufler [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
On Saturday 26 May 2007 07:20, Kyle Moffett wrote:
On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
On Fedora zcat, gzip and gunzip are all links to the same file. I
can imagine (although it is a bit of a stretch) allowing a set of
users access to gunzip but not gzip (or the other way around).
That is a COMPLETE straw-man argument. I can override your check
with this absolutely trivial perl code:
exec { /usr/bin/gunzip } gzip, -9, some/file/to.gz;
The above Perl code executes /usr/bin/gunzip and sets argv[0] to gzip, so
this confirms that the value of argv[0] is arbitrary. Well great, we already
knew.
Pathname-based checks are pretty fundamentally insecure.
Please don't mix apples and pears. Some utilities change their behavior based
on argv[0], which indeed is not secure. It doesn't have to be for those
utilities' needs. This is different from pathname-based access control, which
is based on the pathname of the binary actually being executed.
AppArmor does not look at argv[0] for anything, and doing so would be insane.
So please don't jump to the wrong conclusions.
You can have application-level argv[0] checks in the binary that is hardlinked
to /bin/gzip, /bin/gunzip, /bin/zcat. At the same time, the kernel knows
which of these three versions it is executing, so from that point of view,
they could be as well be separate copies, and different policy can be defined
for each one of them. (This is ignoring the fact that for small utilities
like gzip, profile inheritance is usually more useful than defining separate
profiles.)
Thanks,
Andreas
-
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
On Friday 25 May 2007 21:06, Casey Schaufler wrote: --- Jeremy Maitin-Shepard [EMAIL PROTECTED] wrote: ... Well, my point was exactly that App Armor doesn't (as far as I know) do anything to enforce the argv[0] convention, Sounds like an opportunity for improvement then. Jeez, what argv[0] convention are you both talking about? argv[0] is not guaranteed to have any association with the name of the executable. Feel free to have any discussion about argv[0] you want, but *please* keep it away from AppArmor, which really has nothing to do with it. It would be nice if you could stop calling argv[0] checks ``name-based access control'': from the point of view of the kernel no access control is involved, and even application-level argv[0] based access control makes no sense whatsoever. Thanks, Andreas - 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
As such, AA can detect whether you did exec(gzip) or exec(gunzip) and apply the policy relevant to the program. It could apply different That's not actually useful for programs which link the same binary to multiple names because if you don't consider argv[0] as well I can run /usr/bin/gzip passing argv[0] of gunzip and get one set of policies and the other set of behaviour. And then we have user added hardlinks of course. - 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
On Fri, 25 May 2007, Crispin Cowan wrote: Finally, AA doesn't care what the contents of the executable are. We assume that it is a copy of metasploit or something, and confine it to access only the resources that the policy says. As long as these resources are only files. There is no confinement beyond that. - James -- James Morris [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
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). - James -- James Morris [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
--- Andreas Gruenbacher [EMAIL PROTECTED] wrote: On Friday 25 May 2007 21:06, Casey Schaufler wrote: --- Jeremy Maitin-Shepard [EMAIL PROTECTED] wrote: ... Well, my point was exactly that App Armor doesn't (as far as I know) do anything to enforce the argv[0] convention, Sounds like an opportunity for improvement then. Jeez, what argv[0] convention are you both talking about? From the exec(3) man page: The first argument, by convention, should point to the file name associated with the file being executed. since the man page calls it a convention, so do I. argv[0] is not guaranteed to have any association with the name of the executable. Feel free to have any discussion about argv[0] you want, but *please* keep it away from AppArmor, which really has nothing to do with it. As I pointed out, if you wanted to trust the argv[0] value (which I understand AppArmor makes no claims about) and you wanted to use the argv[0] value to determine application behavior (which several people claim is a Bad Idea) you could use Name Based Access Control to provide different access to the common binary. As I pointed out before, that's a lot of if's. It would be nice if you could stop calling argv[0] checks ``name-based access control'': from the point of view of the kernel no access control is involved, and even application-level argv[0] based access control makes no sense whatsoever. Fair enough, I don't believe that an argv[0] check ought to be used as a security mechanism. I am not convinced that everyone would agree with us. Casey Schaufler [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
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. If you can't properly manage your labels, then how do you expect any security at all? 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. 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. (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. Cheers, Kyle Moffett - 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
On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said: On May 26, 2007, at 19:08:56, Toshiharu Harada wrote: (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. If you can't properly manage your labels, then how do you expect any security at all? Unfortunately, it's not at all as simple as all that. Toshiharu is quite correct that it isn't always easy to actually implement. Consider how many ad-croc usages of 'restorecon' are needed to get a Fedora SELinux box through rc.sysinit: % grep restorecon /etc/rc.sysinit if [ -n $SELINUX_STATE -a -x /sbin/restorecon ] LC_ALL=C fgrep -q /dev /proc/mounts ; then /sbin/restorecon -R /dev 2/dev/null REBOOTFLAG=`restorecon -v /sbin/init` [ -n $SELINUX_STATE ] restorecon /dev/pts /dev/null 21 [ -n $SELINUX_STATE ] restorecon /dev/mapper /dev/mapper/control /dev/null 21 [ -n $SELINUX_STATE -a -e $path ] restorecon -R $path [ -n $SELINUX_STATE -a -e $path ] restorecon -R $path [ -n $SELINUX_STATE -a -e $path ] restorecon -R $path restorecon /etc/mtab /etc/ld.so.cache /etc/blkid/blkid.tab /etc/resolv.conf /dev/null 21 [ -n $SELINUX_STATE ] restorecon /tmp [ -n $SELINUX_STATE ] restorecon /tmp/.ICE-unix /dev/null 21 And that's just getting the system up to single-user. Things like sendmail and sshd require more restorecon handholding in their rc.init files. Or just look at the creeping horror that is 'restorecond' (in particular, consider that the default restorcond.conf contains the strings '~/public_html' and '~/.mozilla/plugins/libflashplayer.so'. Yee. Frikkin. Hah. ;) pgpzQLvdZCrG5.pgp Description: PGP signature
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On May 26, 2007, at 22:37:02, [EMAIL PROTECTED] wrote: On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said: On May 26, 2007, at 19:08:56, Toshiharu Harada wrote: (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. If you can't properly manage your labels, then how do you expect any security at all? Unfortunately, it's not at all as simple as all that. Toshiharu is quite correct that it isn't always easy to actually implement. Consider how many ad-croc usages of 'restorecon' are needed to get a Fedora SELinux box through rc.sysinit: While I don't think restorecon is really necessary to properly boot SELinux-enabled (I've got a Debian box with some heavily customized policy which does so just fine), I am of the opinion that adding a name parameter to the file/directory create actions would be useful. For example, with such support you could actually specify a type-transition rule conditional on a specific name or substring: named_type_transition sshd_t tmp_t:sock_file prefix ssh- ssh_sock_t; Useful options for matching would be prefix, suffix, substr (start,len). regex would be nice but is sorta computationally intensive and would be likely to cause more problems than it solves. /sbin/restorecon -R /dev 2/dev/null [ -n $SELINUX_STATE ] restorecon /dev/mapper /dev/mapper/ control /dev/null 21 These can go away if you modify your policy and pass -o fscontext=system_u:object_r:dev_t to the mount command for the /dev tmpfs, changing both the filesystem and the default directory labels from the default system_u:object_r:tmpfs_t. This will work as long as your policy files contain appropriate transitions from the dev_t type. REBOOTFLAG=`restorecon -v /sbin/init` restorecon /etc/mtab /etc/ld.so.cache /etc/blkid/blkid.tab /etc/ resolv.conf /dev/null 21 [ -n $SELINUX_STATE ] restorecon /tmp [ -n $SELINUX_STATE ] restorecon /tmp/.ICE-unix /dev/null 21 I believe these are to handle rebooting from non-SELinux mode. There are two solutions to this kind of problem: (1) Failing the boot if the labels are wrong (2) Fixing the labels (and rebooting if necessary) It would appear that FC does the latter, although for certain high- security systems (such as firewalls handling classified/confidential data), the first option is the only acceptable one. [ -n $SELINUX_STATE ] restorecon /dev/pts /dev/null 21 I think this can be handled with some combination of appropriate SELinux policy and mount options. At least, I don't need this in the boot scripts on my heavily customized Debian SELinux box. [ -n $SELINUX_STATE -a -e $path ] restorecon -R $path I don't know what the point of this generic line is; but I certainly don't have anything of the sort on my test system, and it appears to work just fine. And that's just getting the system up to single-user. Things like sendmail and sshd require more restorecon handholding in their rc.init files. Or just look at the creeping horror that is 'restorecond' (in particular, consider that the default restorcond.conf contains the strings '~/public_html' and '~/.mozilla/plugins/ libflashplayer.so'. Yee. Frikkin. Hah. ;) Part of the reason that Fedora has a large quantity of that restorecon and restorecond crap is that there is a certain amount of broken binary software needing executable stack/heap (such as flashplayer), programs without comprehensive or complete policies, or programs which by definition need extra support for SELinux. For example, to really complete the SELinux model you need editors and tools which understand security labels the same way they understand UNIX permissions. With a bit of vim scripting I can probably make it run external commands to read file labels before it reads the file itself and modify /proc/self/attr/fscreate before writing out the file, similar to the way it would keep track of the standard DAC permissions on files it modifies. There's also the fact that corporate products have fixed release schedules so remaining bugs in each release tend to get papered over instead of fixed properly (such as the restorecon in FC init- scripts). I haven't seen many problems with the SELinux model which aren't associated with working around buggy software or missing features. Cheers, Kyle Moffett - 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
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
--- Jeremy Maitin-Shepard [EMAIL PROTECTED] wrote: Casey Schaufler [EMAIL PROTECTED] writes: On Fedora zcat, gzip and gunzip are all links to the same file. I can imagine (although it is a bit of a stretch) allowing a set of users access to gunzip but not gzip (or the other way around). There are probably more sophisticated programs that have different behavior based on the name they're invoked by that would provide a more compelling arguement, assuming of course that you buy into the behavior-based-on-name scheme. What I think I'm suggesting is that AppArmor might be useful in addressing the fact that a file with multiple hard links is necessarily constrained to have the same access control on each of those names. That assumes one believes that such behavior is flawwed, and I'm not going to try to argue that. The question was about an example, and there is one. This doesn't work. The behavior depends on argv[0], which is not necessarily the same as the name of the file. Sorry, but I don't understand your objection. If AppArmor is configured to allow everyone access to /bin/gzip but only some people access to /bin/gunzip and (important detail) the single binary uses argv[0] as documented and (another important detail) there aren't other links named gunzip to the binary (ok, that's lots of if's) you should be fine. I suppose you could make a shell that lies to exec, but the AppArmor code could certainly check for that in exec by enforcing the argv[0] convention. It would be perfectly reasonable for a system that is so dependent on pathnames to require that. Casey Schaufler [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
Casey Schaufler [EMAIL PROTECTED] writes: --- Jeremy Maitin-Shepard [EMAIL PROTECTED] wrote: Casey Schaufler [EMAIL PROTECTED] writes: On Fedora zcat, gzip and gunzip are all links to the same file. I can imagine (although it is a bit of a stretch) allowing a set of users access to gunzip but not gzip (or the other way around). There are probably more sophisticated programs that have different behavior based on the name they're invoked by that would provide a more compelling arguement, assuming of course that you buy into the behavior-based-on-name scheme. What I think I'm suggesting is that AppArmor might be useful in addressing the fact that a file with multiple hard links is necessarily constrained to have the same access control on each of those names. That assumes one believes that such behavior is flawwed, and I'm not going to try to argue that. The question was about an example, and there is one. This doesn't work. The behavior depends on argv[0], which is not necessarily the same as the name of the file. Sorry, but I don't understand your objection. If AppArmor is configured to allow everyone access to /bin/gzip but only some people access to /bin/gunzip and (important detail) the single binary uses argv[0] as documented and (another important detail) there aren't other links named gunzip to the binary (ok, that's lots of if's) you should be fine. I suppose you could make a shell that lies to exec, but the AppArmor code could certainly check for that in exec by enforcing the argv[0] convention. It would be perfectly reasonable for a system that is so dependent on pathnames to require that. Well, my point was exactly that App Armor doesn't (as far as I know) do anything to enforce the argv[0] convention, nor would it in general prevent a confined program from making a symlink or hard link. Even disregarding that, it seems very fragile in general to make an suid program (there would be no point in confining the execution of a non-suid program) perform essentially access control based on argv[0]. -- Jeremy Maitin-Shepard - 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
--- Jeremy Maitin-Shepard [EMAIL PROTECTED] wrote: ... Well, my point was exactly that App Armor doesn't (as far as I know) do anything to enforce the argv[0] convention, Sounds like an opportunity for improvement then. nor would it in general prevent a confined program from making a symlink or hard link. Even disregarding that, it seems very fragile in general to make an suid program (there would be no point in confining the execution of a non-suid program) perform essentially access control based on argv[0]. I think that you're being generous calling it fragile, but that's my view, and I've seen much worse. I agree that it would be a Bad Idea, but the fact that I think it's a bad idea is not going to prevent very many people from trying it, and for those that do try it name based access control might seem like just the ticket to complete their nefarious schemes. Remember that security is a subjective thing, and using argv[0] and AppArmor together might make some people feel better. Casey Schaufler [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
On Friday 25 May 2007 19:43, Casey Schaufler wrote: [...] but the AppArmor code could certainly check for that in exec by enforcing the argv[0] convention. It would be perfectly reasonable for a system that is so dependent on pathnames to require that. Hmm ... that's a strange idea. AppArmor cannot assume anything about argv[0], and it would be a really bad idea to change the well-established semantics of argv[0]. There is no actual need for looking at argv[0], though: AppArmor decides based on the actual pathname of the executable... Thanks, Andreas - 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
--- Andreas Gruenbacher [EMAIL PROTECTED] wrote: On Friday 25 May 2007 19:43, Casey Schaufler wrote: [...] but the AppArmor code could certainly check for that in exec by enforcing the argv[0] convention. It would be perfectly reasonable for a system that is so dependent on pathnames to require that. Hmm ... that's a strange idea. Yeah, I get that a lot. AppArmor cannot assume anything about argv[0], and it would be a really bad idea to change the well-established semantics of argv[0]. There is no actual need for looking at argv[0], though: AppArmor decides based on the actual pathname of the executable... Right. My point was that if you wanted to use the gzip/gunzip example of a file with two names being treated differently based on the name accessed as an argument for AppArmor you could. If you don't want to, that's ok too. Jeremy raised a reasonable objection, and AppArmor could address it if y'all chose to do so. I seriously doubt that enforcing the argv[0] convention would break much, and I also expect that if it did there's a Consultant's Retirement to be made fixing the security hole it points out. Casey Schaufler [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
Hello. Casey Schaufler wrote: Sorry, but I don't understand your objection. If AppArmor is configured to allow everyone access to /bin/gzip but only some people access to /bin/gunzip and (important detail) the single binary uses argv[0] as documented and (another important detail) there aren't other links named gunzip to the binary (ok, that's lots of if's) you should be fine. The argv[0] defines the default behavior of hard linked or symbolic linked programs, but the behavior can be overridden using commandline options. If you want to allow access to /bin/gzip but deny access to /bin/gunzip , you also need to deny access to /bin/gzip -d /bin/gzip --decompress /bin/gzip --uncompress. It is impossible to do so because options to override the default behavior depends on program's design and you can't know what programs and what options are there in the system. Even if you know all programs and all options in the system, it is a too tough job to find and reject options that override the default behavior in the kernel space. Well, my point was exactly that App Armor doesn't (as far as I know) do anything to enforce the argv[0] convention, Sounds like an opportunity for improvement then. There are (I think) three types of program invocation. (1) Invocation of hard linked programs. /bin/gzip and /bin/gunzip and /bin/zcat are hard links. There is no problem because you can know which pathname was requested using d_namespace_path() with struct linux_binprm-file . (2) Invocation of symbolic linked programs. /sbin/pidof is a symbolic link to /sbin/killall . There is a problem because you can't know which pathname was requested using d_namespace_path() with struct linux_binprm-file because the symbolic links were already derefernced inside open_exec(). To know which pathname was requested, you need to lookup using struct linux_binprm-filename without LOOKUP_FOLLOW and then use d_namespace_path(). Although there is a race condition that the pathname the symbolic link struct linux_binprm-filename points to may change, but it is inevitable because you can't get dentry and vfsmount of both without LOOKUP_FOLLOW flag and with LOOKUP_FOLLOW flag at the same time. (3) Invocation of dynamically created programs with random names. /usr/sbin/logrotate creates files patterned /tmp/logrotate.?? and executes these dynamically created files. To keep execution of these dynamically created files under control, you need to aggregate pathnames of these files. AppArmor can't define profile if the pathname of programs is random, can it? Usually the argv[0] and the struct linux_binprm-filename are the same, but if you want to do something with argv[0], you will need to handle the (2) case to see whether the argv[0] and struct linux_binprm-filename are the same. Thanks. - 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
On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
On Fedora zcat, gzip and gunzip are all links to the same file. I
can imagine (although it is a bit of a stretch) allowing a set of
users access to gunzip but not gzip (or the other way around).
That is a COMPLETE straw-man argument. I can override your check
with this absolutely trivial perl code:
exec { /usr/bin/gunzip } gzip, -9, some/file/to.gz;
Pathname-based checks are pretty fundamentally insecure. If you want
to protect a name, then you should tag the name with security
attributes (IE: AppArmor). On the other hand, if you actually want
to protect the _data_, then tagging the _name_ is flawed; tag the
*DATA* instead.
Cheers,
Kyle Moffett
-
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
Casey Schaufler wrote: --- Andreas Gruenbacher [EMAIL PROTECTED] wrote: AppArmor cannot assume anything about argv[0], and it would be a really bad idea to change the well-established semantics of argv[0]. There is no actual need for looking at argv[0], though: AppArmor decides based on the actual pathname of the executable... Right. My point was that if you wanted to use the gzip/gunzip example of a file with two names being treated differently based on the name accessed as an argument for AppArmor you could. AppArmor detects the pathname of the file exec'd at the time the parent exec's it, and not anything inside the child involving argv[0]. As such, AA can detect whether you did exec(gzip) or exec(gunzip) and apply the policy relevant to the program. It could apply different policies to each of them, so whether it has access to /tmp/mumble/barf depends on whether you called it 'gzip' or 'gunzip'. Caveat: it makes no sense to profile either gzip or gunzip in the AppArmor model, so I won't defend what kind of policy you would put on them. Finally, AA doesn't care what the contents of the executable are. We assume that it is a copy of metasploit or something, and confine it to access only the resources that the policy says. If you don't want to, that's ok too. Jeremy raised a reasonable objection, and AppArmor could address it if y'all chose to do so. I seriously doubt that enforcing the argv[0] convention would break much, and I also expect that if it did there's a Consultant's Retirement to be made fixing the security hole it points out. AppArmor does address it, and I hope this explains how we detect which of multiple hard links to a file you used to access the file without mucking about with argv[0]. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - 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
On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote: Read it like this: we don't have a good idea how to support multiple namespaces so far. Currently, we interpret all pathnames relative to the namespace a process is in. Confined processes don't have the privilege to create or manipulate namespaces, which makes this safe. We may find a better future solution. You also don't have a solution for multiple chroot jails, since they often have the same fs mounted in many places on given box *and* since the pathnames from the confined processes' POVs have fsck-all to do with each other. It's really not kinder than multiple namespaces as far as your approach is concerned. - 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
--- Andreas Gruenbacher [EMAIL PROTECTED] wrote: 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 ? I'm not aware of situations where giving different permissions to different paths to the same file would actually be useful. The security model doesn't prevent it though, and it's not a security hole. On Fedora zcat, gzip and gunzip are all links to the same file. I can imagine (although it is a bit of a stretch) allowing a set of users access to gunzip but not gzip (or the other way around). There are probably more sophisticated programs that have different behavior based on the name they're invoked by that would provide a more compelling arguement, assuming of course that you buy into the behavior-based-on-name scheme. What I think I'm suggesting is that AppArmor might be useful in addressing the fact that a file with multiple hard links is necessarily constrained to have the same access control on each of those names. That assumes one believes that such behavior is flawwed, and I'm not going to try to argue that. The question was about an example, and there is one. Casey Schaufler [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
On Thursday 24 May 2007 20:40, Al Viro wrote: On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote: Read it like this: we don't have a good idea how to support multiple namespaces so far. Currently, we interpret all pathnames relative to the namespace a process is in. Confined processes don't have the privilege to create or manipulate namespaces, which makes this safe. We may find a better future solution. You also don't have a solution for multiple chroot jails, since they often have the same fs mounted in many places on given box *and* since the pathnames from the confined processes' POVs have fsck-all to do with each other. It's really not kinder than multiple namespaces as far as your approach is concerned. Well, the pathnames we check against are namespace relative, so no matter what pathnames the chrooted processes think they are looking at, we always know the actual pathnames up to ``outside the chroot''. Having the same filesystem mounted in multiple chroots or in multiple locations in the same chroot doesn't matter. The main problem I see when it comes to defining per-namespace policy is that namespaces are inherently anonymous, and there is no obvious way of associating different sets of profiles with different namespaces. Implementing something to also handle multiple namespaces doesn't seem hard -- after all, it's not such a difficult concept -- but I don't have a good enough idea what would work best. Thanks, Andreas - 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
On Thursday 24 May 2007 20:58, Casey Schaufler wrote: On Fedora zcat, gzip and gunzip are all links to the same file. I can imagine (although it is a bit of a stretch) allowing a set of users access to gunzip but not gzip (or the other way around). There are probably more sophisticated programs that have different behavior based on the name they're invoked by that would provide a more compelling arguement, assuming of course that you buy into the behavior-based-on-name scheme. What I think I'm suggesting is that AppArmor might be useful in addressing the fact that a file with multiple hard links is necessarily constrained to have the same access control on each of those names. That assumes one believes that such behavior is flawwed, and I'm not going to try to argue that. The question was about an example, and there is one. Different policy for different names of the same binary makes more obvious sense with chroot environments. That's slightly different from having different permissions for the same file within a single profile though. Thanks, Andreas - 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
Casey Schaufler [EMAIL PROTECTED] writes: On Fedora zcat, gzip and gunzip are all links to the same file. I can imagine (although it is a bit of a stretch) allowing a set of users access to gunzip but not gzip (or the other way around). There are probably more sophisticated programs that have different behavior based on the name they're invoked by that would provide a more compelling arguement, assuming of course that you buy into the behavior-based-on-name scheme. What I think I'm suggesting is that AppArmor might be useful in addressing the fact that a file with multiple hard links is necessarily constrained to have the same access control on each of those names. That assumes one believes that such behavior is flawwed, and I'm not going to try to argue that. The question was about an example, and there is one. This doesn't work. The behavior depends on argv[0], which is not necessarily the same as the name of the file. -- Jeremy Maitin-Shepard - 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
On Thursday 12 April 2007 12:12, Al Viro wrote: On Thu, Apr 12, 2007 at 02:08:10AM -0700, [EMAIL PROTECTED] wrote: This is needed for computing pathnames in the AppArmor LSM. Which is an argument against said LSM in current form. The fundamental model of AppArmor is to perform access checks based on the location of a file in the filesystem namespace, i.e., the pathname, and this can only be done with both the dentry and vfsmount. My understanding was that there was agreement at the last kernel summit that pathname based approaches should be allowed. - error = security_inode_create(dir, dentry, mode); + error = security_inode_create(dir, dentry, nd ? nd-mnt : NULL, mode); is a clear sign that interface is wrong. No. There are callers of vfs_create() that use a NULL nameidata, and that's what causes the problem here. Struct nameidata is pretty big, and so we don't want to allocate temporary nameidata objects all over the place. So to me the above NULL check seems the lesser evil. One way to deal with the nameidata size problem is to split it up into one part for the real path lookups, and a much smaller part that only contains the dentry, vfsmount, and intent flags. This would allow to pass around the smaller nameidata much more consistently. John has posted patches for that on May 14; subject [RFD Patch 0/4]. Feedback appreciated. In several places, the NULL nameidata is wrong because we can't check the vfsmount flags or intent. Not having this information is causing problems for nfs too for example -- it's not an AppArmor specific problem. Leaving aside the general idiocy of we prohibit to do something with file if mounted here, but if there's another mountpoint, well, we just miss, an API of that kind is just plain wrong. Either you can live without seeing vfsmount in that method (in which case you shouldn't pass it at all), or you have a hole. This is backwards from what AppArmor does. The policy defines which paths may be accessed; all paths not explicitly listed are denied. If files are mounted at multiple locations, then the policy may allow access to some locations but not to others. That's not a hole. In fact this is not much different from traditional permissions on parent directories: even if the same files are mounted at several locations, parent directory permissions may allow accessing only some of those locations. Thanks, Andreas - 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
On Wed, 23 May 2007, Andreas Gruenbacher wrote: This is backwards from what AppArmor does. The policy defines which paths may be accessed; all paths not explicitly listed are denied. If files are mounted at multiple locations, then the policy may allow access to some locations but not to others. That's not a hole. I don't know what else you'd call it. Would you mind providing some concrete examples of how such a model would be useful? - James -- James Morris [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
[AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
This is needed for computing pathnames in the AppArmor LSM.
Signed-off-by: Tony Jones [EMAIL PROTECTED]
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
Signed-off-by: John Johansen [EMAIL PROTECTED]
---
fs/namei.c |2 +-
include/linux/security.h |9 ++---
security/dummy.c |2 +-
security/selinux/hooks.c |3 ++-
4 files changed, 10 insertions(+), 6 deletions(-)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1503,7 +1503,7 @@ int vfs_create(struct inode *dir, struct
return -EACCES; /* shouldn't it be ENOSYS? */
mode = S_IALLUGO;
mode |= S_IFREG;
- error = security_inode_create(dir, dentry, mode);
+ error = security_inode_create(dir, dentry, nd ? nd-mnt : NULL, mode);
if (error)
return error;
DQUOT_INIT(dir);
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -283,6 +283,7 @@ struct request_sock;
* Check permission to create a regular file.
* @dir contains inode structure of the parent of the new file.
* @dentry contains the dentry structure for the file to be created.
+ * @mnt is the vfsmount corresponding to @dentry (may be NULL).
* @mode contains the file mode of the file to be created.
* Return 0 if permission is granted.
* @inode_link:
@@ -1204,8 +1205,8 @@ struct security_operations {
void (*inode_free_security) (struct inode *inode);
int (*inode_init_security) (struct inode *inode, struct inode *dir,
char **name, void **value, size_t *len);
- int (*inode_create) (struct inode *dir,
-struct dentry *dentry, int mode);
+ int (*inode_create) (struct inode *dir, struct dentry *dentry,
+struct vfsmount *mnt, int mode);
int (*inode_link) (struct dentry *old_dentry,
struct inode *dir, struct dentry *new_dentry);
int (*inode_unlink) (struct inode *dir, struct dentry *dentry);
@@ -1611,11 +1612,12 @@ static inline int security_inode_init_se
static inline int security_inode_create (struct inode *dir,
struct dentry *dentry,
+struct vfsmount *mnt,
int mode)
{
if (unlikely (IS_PRIVATE (dir)))
return 0;
- return security_ops-inode_create (dir, dentry, mode);
+ return security_ops-inode_create (dir, dentry, mnt, mode);
}
static inline int security_inode_link (struct dentry *old_dentry,
@@ -2338,6 +2340,7 @@ static inline int security_inode_init_se
static inline int security_inode_create (struct inode *dir,
struct dentry *dentry,
+struct vfsmount *mnt,
int mode)
{
return 0;
--- a/security/dummy.c
+++ b/security/dummy.c
@@ -265,7 +265,7 @@ static int dummy_inode_init_security (st
}
static int dummy_inode_create (struct inode *inode, struct dentry *dentry,
- int mask)
+ struct vfsmount *mnt, int mask)
{
return 0;
}
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2178,7 +2178,8 @@ static int selinux_inode_init_security(s
return 0;
}
-static int selinux_inode_create(struct inode *dir, struct dentry *dentry, int
mask)
+static int selinux_inode_create(struct inode *dir, struct dentry *dentry,
+struct vfsmount *mnt, int mask)
{
return may_create(dir, dentry, SECCLASS_FILE);
}
--
-
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
On Thu, Apr 12, 2007 at 02:08:10AM -0700, [EMAIL PROTECTED] wrote: This is needed for computing pathnames in the AppArmor LSM. Which is an argument against said LSM in current form. - error = security_inode_create(dir, dentry, mode); + error = security_inode_create(dir, dentry, nd ? nd-mnt : NULL, mode); is a clear sign that interface is wrong. Leaving aside the general idiocy of we prohibit to do something with file if mounted here, but if there's another mountpoint, well, we just miss, an API of that kind is just plain wrong. Either you can live without seeing vfsmount in that method (in which case you shouldn't pass it at all), or you have a hole. NACK. - 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
