[opensuse-factory] Security issue: Proposal to revert to '/' on sep. part. from /usr,/home,/tmp,/var, etc
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
On Mon, Mar 31, 2014 at 4:42 PM, Linda Walsh <suse@tlinx.org> wrote:
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.
Have you at least googled the issue? The security hole was pre-existing, and its introduction has nothing to do with partitioning (unless you plan to make one partition per user?). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Claudio Freire wrote:
On Mon, Mar 31, 2014 at 4:42 PM, Linda Walsh <suse@tlinx.org> wrote:
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.
Have you at least googled the issue?
The security hole was pre-existing, and its introduction has nothing to do with partitioning (unless you plan to make one partition per user?).
No, it wasn't. The first and main issue was:( from https://lwn.net/Articles/482544/) On systems that have user-writable directories on the same partition as system files, a long-standing class of security issues is the hardlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp. Putting system files on separate partitions was a way of preventing the main exploits. Another more arcane case of setUID/GID files would be better served by disallowing that specific case if the user was not in the user(SUID) or group(SGID). Or do you have another situation not documented ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Mar 31, 2014 at 6:35 PM, Linda Walsh <suse@tlinx.org> wrote:
No, it wasn't.
The first and main issue was:( from https://lwn.net/Articles/482544/)
On systems that have user-writable directories on the same partition as system files, a long-standing class of security issues is the hardlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp.
Yes, the problem here is that all systems (except those partitioned excessively and paranoically as in one partition per user) have user-writeable system partitions. /tmp is a good example that didn't change, you also have /var/spool (you've got many daemons that can write there and thus, if you manage to compromise them, compromise the whole system in turn). I could probably find other examples - thing is, this protection was necessary before, and still is. Also... I didn't see in the OP any proposal to improve the current state. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Claudio Freire wrote:
On Mon, Mar 31, 2014 at 6:35 PM, Linda Walsh <suse@tlinx.org> wrote:
No, it wasn't.
The first and main issue was:( from https://lwn.net/Articles/482544/)
On systems that have user-writable directories on the same partition as system files, a long-standing class of security issues is the hardlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp.
Yes, the problem here is that all systems (except those partitioned excessively and paranoically as in one partition per user) have user-writeable system partitions.
You don't need separate / user you need users separate from system. you may also need to disallow creating world-writeable files in world-writeable directories like tmp.
/tmp is a good example that didn't change;
--- There have been multiple proposals for users to use ~/.tmp as on windows or to use fs-namespace separation to achieve the same. However, a file owned by root in /tmp wouldn't be linkable except to another file in /tmp owned by root...what does that buy you? Current setup (its changed over the years) / 1 partition /usr 1 partition /usr/share 1 partition (mostly due to overflowing /usr) /var - 1 partition /tmp - 1 partition, though later sharing space on /var /home separate /var/cache - separate partition. /var/spool was separate at one point but is part of /var now. ---- different daemons ran as different user & group so as not to have access to other daemon's files, automatically (another change, BTW, that I pushed for via multiple bug reports).
(you've got many daemons that can write there and thus, if you manage to compromise them, compromise the whole system in turn).
not if they are each in their own userspace.
I could probably find other examples - thing is, this protection was necessary before, and still is.
--- Not by any of the reasons you gave above.
Also... I didn't see in the OP any proposal to improve the current state.
---- See the above. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 31/03/14 18:51, Claudio Freire escribió:
(you've got many daemons that can write there and thus, if you manage to compromise them, compromise the whole system in turn).
Nowdays, those daemons run (or should run) with a private /tmp namespace, separated from the host. then this issue is effectively dealt with. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Mar 31, 2014 at 7:08 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
(you've got many daemons that can write there and thus, if you manage to compromise them, compromise the whole system in turn).
Nowdays, those daemons run (or should run) with a private /tmp namespace, separated from the host. then this issue is effectively dealt with.
I meant "write in /var/spool".
From /var/spool you can pivot and compromise other daemons, eventually reaching one with which you can escalate to root.
I haven't tried, it's quite labour-intensive, but it is conceivable. On Mon, Mar 31, 2014 at 7:06 PM, Linda Walsh <suse@tlinx.org> wrote:
Claudio Freire wrote:
On Mon, Mar 31, 2014 at 6:35 PM, Linda Walsh <suse@tlinx.org> wrote:
No, it wasn't.
The first and main issue was:( from https://lwn.net/Articles/482544/)
On systems that have user-writable directories on the same partition as system files, a long-standing class of security issues is the hardlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp.
Yes, the problem here is that all systems (except those partitioned excessively and paranoically as in one partition per user) have user-writeable system partitions.
---- You don't need separate / user you need users separate from system. you may also need to disallow creating world-writeable files in world-writeable directories like tmp.
/tmp is a good example that didn't change;
--- There have been multiple proposals for users to use ~/.tmp as on windows or to use fs-namespace separation to achieve the same. However, a file owned by root in /tmp wouldn't be linkable except to another file in /tmp owned by root...what does that buy you?
Without separating each user in their own namespace, you can induce remote execution by tampering with other applications' temporary files. You can never assume compromising an unprivileged user to be less sensitive than compromising root - that user might have sudo powers or otherwise be important. Here[0][1] you have an old case involving /var/spool (mailbox delivery). Googling, I found this one[2] involving /tmp. Clearly, this is not something new. [0] http://www.postfix.org/announcements/20080814.html [1] http://lwn.net/Articles/391474/} [2] http://50.97.85.250-static.reverse.softlayer.com/show/osvdb/96901 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Claudio Freire wrote
Here[0][1] you have an old case involving /var/spool (mailbox delivery).
Googling, I found this one[2] involving /tmp.
Clearly, this is not something new.
==== Those both involve directories with sticky bits that are world writeable. That's a special case. which could be dealt with as not allowing linking to a file owned by someone else in a world writable sticky directory. There is no need to generalize it to all files .
[0] http://www.postfix.org/announcements/20080814.html [1] http://lwn.net/Articles/391474/} [2] http://50.97.85.250-static.reverse.softlayer.com/show/osvdb/96901 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Claudio Freire -
Cristian Rodríguez -
Linda Walsh