Keith, thanks for your comments. I found them quite informative and helpful in understanding this issue. I think that everyone on this list would agree that system security is an important topic, and one that will continue to increase in importance as more and more systems are connected to the Internet, and more aspects of our daily lives are carried out on the Internet. I would like to share some thoughts and opinions on your response as they pertain to modutils, and to software development in general, which I hope you and the community will find useful or thought-provoking, even if you don't agree with everything I say here. On Wed, Jul 18, 2001 at 09:59:43AM +1000, Keith Owens wrote: > >I would think that modutils should set the creation mode to 0644 when > >creating these files. I would also think that as a security measure, > >modutils should verify that these files (or at least modules.dep) are > >not world-writable (and probably also not group writable) BEFORE > >loading modules as a result of listed dependencies... > > When programs should force security settings and when they should trust > the umask is a policy question. I agree with this statement; but I think it warrants further consideration. I'm a system administrator, and by the nature of my job I have a different philosophy about how things should be configured than software/OS developers typically do. The sysadmin generally leans toward security, and the developer leans toward ease of use (openness). Neither philosophy is wrong, they're just different; and each should be used when it is appropriate. For the most part, most of these two groups knows how to configure their system for what they want, or at least is technical enough to go about figuring out how... But there also is a growing third group of people emerging as Linux users: the average Joe. There are many reasons why people are moving to Linux today, not the least of which is Microsoft's renowned buggy and/or insecure code, and the fact that Linux advocates keep saying that Linux is more reliable and more secure than Windows (which I agree with based on my own experience). Whether or not that's actually true or provable, that's what people are saying, and it's bringing the non-technical computer user into the Linux forefront. These people have no idea what information assurance/network security is, never mind how to configure their systems for it. These people have no idea what they're getting themselves into when they install a Linux system (using the average distribution's standard installs) and connecting it up to the Internet. Odds are these days that they'll be hacked within a week, and probably less. Because of the potential seriousness of the consequences of having your systems and data compromised, and because of the negative impact going through this experience can have on users new to Linux (or experienced ones for that matter), I think that for the good of the entire Linux community, the development community ought to make security a priority. In other words, yes, developers will want to do things that would put most other Linux users at risk; HOWEVER, while I think it should be possible for them to do those things, I also think it should be HARDER to configure your system to be less secure than it should be to have it configured reletively securely for every day use. (I'm deliberately trying to avoid absolutes because, as we all know, in practice there is no such thing as a completely secure machine -- at least not one that's usable by anyone -- and improving security negatively impacts convenience and usability. A balance must be struck somehow. I'll dance around that a little more below.) That is to say, you should have to make a deliberate effort to reduce the security of your machine, if you need to do so for development or whatever other reason... Or said another way, if a particular software package (or the kernel itself) can be used in a way which is known to open up your system to root compromises, that should NOT be the default: the program which is capable of this should not assume anything about the environment it runs in (like umask) if incorrect assumtions result in a root compromise or other unauthorized elevated priviledge. I might go so far as to say it should assume the worst-case scenario (e.g. for this case, that the umask will always be 000), in order to prevent . > Users on development systems deliberately create modules.dep as 666 > and allow modules to be owned as other than root so modutils allows > this. In this case I decided that the policy setting should come > from the user via umask, instead of being forced by the programs. At least on my "broken" Red Hat 6.2 system, you can still do this if modutils creates the files 0644. Except you must do it explicitly. If you chmod the files to 0666, they will retain those permissions (assuming the given distribution doesn't go out of it's way to remove the modules.* files) after subsequent reboots. But the burden to make the system less secure, and the responsibility for the consequences, has been placed on the user/administrator, where I think it belongs. > If root's umask is 000 then lots of programs are insecure, should > all of those programs be changed to ignore umask? First, you're not ignoring umask. You're simply defining a minimum set of permissions that the file(s) should have by default. I think this is reasonable to do. Maybe you can make it a compile-time option... In any case, you could set root's umask to 077, and the files would then be created 0600 (ignoring whether or not this would break things)... As to whether or not you want your processes to use pre-defined minimum permissions, my answer would be a qualified "YES!" The qualification is that it should only be done in cases where a) it will not make the software unusable, and b) not doing it can easily result in an elevation of priviledges of a regular user, where the only mitigating factor is the environment of a given process, about which I think you must not make assumptions. This particular case is a good example of what I mean: a root compromise is possible if the distribution maintainer(s) or the system administrators forget/overlook/fail to see the need to set the umask "properly" to avoid the problem. An operating system is complex; with all the software that comes with your average Linux distribution -- written by a wide variety of individuals with (usually) no particular holistic design philosophy, such as a proprietary OS (ostensibly) has -- I should think that putting together such a beast is even more complex than designing a proprietary OS would be. It should be expected that the people who build distributions WILL overlook these little details, as it happens all the time, as this case illustrates. If you, as the software developer -- the guy (or gal) who knows the code better than anyone else -- can prevent this from happening, without actually preventing those who NEED to open up the system from being able to do so, then I think it's in your best interest and the interest of the community as a whole that you do so. Some might even argue you have a duty to do so. Exactly that is argued about Microsoft all the time, often by the Linux development community itself. I'm disinclined to say you have that duty. I think that Linux developers largely write software to suit their needs, and have no responsibility to anyone to do anything they don't want to. You are giving your work away for free, after all... On the other hand, I do think that all of us who develop software which we intend for others to use, especially in networked environments and especially on the Internet, do have some responsibility to make every effort to ensure that our software does not cause the systems and data of its user to become compromised, unavailable, or damaged. I sincerely hope that everyone writing software will take that responsibility seriously; as our society becomes more dependent upon the Internet and network-connected technologies, it also becomes more vulnerable to careless and insecure coding practices, and we all play a part in that. Thanks. -- --------------------------------------------------- Derek Martin | Unix/Linux geek ddmat_private | GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu
This archive was generated by hypermail 2b30 : Wed Jul 18 2001 - 08:18:25 PDT