WTF? Am I crazy? Following is a chain of logical events that have happened and are likely to happen that will cause even more security patches to compensate for the merge of '/' with other partitions (include /usr/share -- which was supposed to be independently sharable, yet the keyboard services needs it to load 'locales'). The conclusion is at the end, if you are one of those who are impaired with the TLDR disease. Well, yeah, and? The new setup is being used as a justification for a need for a new and ill designed security feature: "protected_hardlinks" that disables standard, legacy linking ability. In 13.1, this feature is turned on by default. That causes side effects, like not being able to copy a R/O source-tree with "cp -al", into a 2nd copy of symlinked dirs w/hard-linked file objects. To me, that was a basic source control mechanism -- anything that was the same between the two (or 20 trees) shared the same file and was read-only as someone other than the owner of the original source tree (often root). Local mods in source files could be made in your source tree but they wouldn't propagate to to the source copy. Now, such a setup is impossible in the default suse config unless a user has access to root and/or is willing to risk overwriting the original source. The main justification for protected_hardlinks was to protect users from linking to files that used to be on *separate* file systems (/etc/{shadow,group,passwd}) to use for some further exploit -- claim a lost of files and a need for their homedir to be restored via some util that writes to a hardlinked file w/root privs, for example. But now, along comes the protected_hardlinks feature which doesn't do the same job. It allows linking, only, to _regular files_ that you have write access to. Logically, to get around the inability to link w/o write access, one might think to make sure the copying user is in the same group as the target files and use group write access. That causes 2 problems: 1) it doesn't solve the original requirement of keeping the original source tree read-only to other users (i.e. if the users have write access through the group, they can overwrite the original, but worse, 2) protected_hardlinks was implemented to inconsistently allow hardlinking to objects in in the source tree. While it used to be the case that one could hardlink to any readable non-directory on the same device, protected_hardlinks changes that to allow hard-linking not just to "writeable" files, but only *regular files*. This means for example, that the kernel source tree can no longer be copied by anyone other than the tree owner due to symlink usage in the kernel (that were previously hardlinked to):
find . -type l|xargs ls -dgGl|cut -c30-999 ./arch/arm/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings ./arch/metag/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings ./arch/microblaze/boot/dts/system.dts -> ../../platform/generic/system.dts ./arch/mips/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings ./arch/powerpc/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings
Of less commonality, but also affected were hardlinks to named pipes, sockets, -- any other file system object -- except for dirs which, on linux, have pretty much always been disallowed. Notably, now, we have a broken workaround to re-create security lost by previously having a separate root (broken in that it only partly works for some objects), but it's already being discussed how utility (applications will have to follow) progs will deal with making copies when "cp -al" is used -- i.e. it is likely that linux will fall back to DOS-level functionality where copies are made for any file object that doesn't support linking. This has a further security impact: any ACL's or security labels on a readable file will be stripped unless the copying user has the ability to recreate them (often not true if the source tree was designed to be read-only to the copier). I found that to already by a problem when 'mv'ing files -- a few samba versions mistakenly put NT-acl's in the 'security' or 'system' namespace, when such ACL's are not native acls, but a user-app (samba) level data-blob. That issue was raised with the samba team, and it appears it will be addressed, though no official statement was made about the security hole (a Windows user who has login access to the domain will be able to, by default, strip the file of it's NT-ACL just by moving it to another partition or by copying it (whether they intend this or not -- it's not a good side-effect). ========================= **TLDR: In short, the joining of the partitions has already caused broken security workarounds to go into the kernel (that still need to be fixed), and is in the process of requiring system utils and applications to invent workarounds for the security implications -- that themselves cause their own set of security issues that will need more patches, and likely cause more rounds. I.e. this is a case of a bad decision causing a chain of worsening and growing side effects. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org