On Thu, 2004-10-07 at 03:07, Nathan G. Grennan wrote: > So the move command is obsolete, and all users will figure this out and > accept it? The mv command preserve protections by default, as expected. A similar issue would arise if the original ownership and mode bits on the file prior to moving prevented access by apache, right? > It should be obvious that I am exposing it when I move it > to /var/www/html. As above, do you expect mv to rewrite the DAC ownership and mode bits when you move a file to /var/www/html? And note that the pathname by which you access a file tells us nothing useful about its protection requirements; a single file may have many names via multiple hard links, bind mounts, etc, and letting people bypass protection by using a different name is a classic security flaw. > I have seen users accidentally upload data to /home/user, instead > of /home/public_html and then move it. A user may also want to upload > big files like isos before a release to /home/user, and then move them > into /home/user/public_html when the time is right. Users will do all > kinds of things you can think of doing. And they already have to deal with setting mode bits. Running restorecon on the file as an extra step is just an education issue. > So it is good to be broken out of the box? This is also just one case > with one service. I am sure many more such problems will come up. I > think that SELinux should be more transparent to the user before > becoming the default. Improved transparency is certainly a good thing, but you are imposing an unfair requirement on SELinux that does not exist for the existing DAC protections and total transparency would just mean no protection at all. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
