mjhjmtu

Picture a scenario in which you have a parent and a child directory. In the parent directory you have given group rwx. Below that directory you have a directory in which the group permissions are --- (so no permissions.) Is this secure? Why or why not?

This setup immediately struck me as not secure; my original thinking was that since group had all permissions in the parent directory, they can change the permissions of the child. But when we tested this theory it didn't work.
I created a directory Test and changed permissions with chmod 777 Test; then, inside that directory, I created a directory ChildTest and set permissions with chmod 700 ChildTest, thereby setting up the parameters in the question.
Then my friend cd'd into my Test directory and tried several different things to try to access ChildTest: (Our HP/UX environment uses ksh)

cp -R ChildTest ~
chmod 777 ChildTest
mkdir New
mv ChildTest New # (also tried this with cp)

All of which fail because he did not own ChildTest. So we were thinking maybe it was more secure than we thought. We asked the professor, who again, alluded to the fact that it wasn't secure at all, but wouldn't give us any information more than "You need to do it with two people, because its too easy to change your own permissions" (which really confused us because... we were?)

So anyway, I'm sure that this set up is in fact not secure, but I just don't know how to prove it. I don't want the answer given to me, but maybe just a push in the right direction or confirmation that I'm on the right track would be great.

Indeed: you cannot change permissions of the child directory because the permissions are stored per-file/directory in -what is called- the "inode". In that respect it is secure.

But the name of the child directory is stored in the parent directory, as a directory is a special file that contains the names of the files (and as such child directories too) it contains. And in the parent directory every user/group has got write permissions.

Therefore a user who does not own the child directory can rename it, or remove the child directory if it is empty. On some systems it may even be moved to another directory where he/she has write permissions if it's in the same file system.

By POSIX, changing the subdirectory permissions should not work:

Only a process whose effective user ID matches the user ID of the file, or a process with appropriate privileges, shall be permitted to change the file mode bits of a file.

But the rename should work, it only requires write access to the containing directory:

(root) /tmp# mkdir -p one/two; chmod 0777 one; chmod 0700 one/two
(user) /tmp/one$ mv two three && echo ok
ok

Though at least on Linux, setting the sticky bit will prevent that, as it will prevent removing files and directories you don't own:

(root) /tmp# chmod +t one
(user) /tmp/one$ mv three four
mv: cannot move 'three' to 'four': Operation not permitted

I'll freely admit I have no idea about any HP-UX specific features that would affect this.

How much of a problem it is that someone could rename the subdirectory depends on what you're doing with those directories. The user who has access only to the the top-level directory can't read any files in the subdirectory so in that sense you're safe. But since they can rename and recreate a directory with the same name, they could impersonate whatever is supposed to be there.

That would matter if e.g. some external service reads files in the subdirectory. Think something like the directory where crontab files are kept; you wouldn't want anyone to be able to create a crontab in someone else's name.