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(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
