� wrote:
Yes, the can be overridden in /etc/sysctl.d. But I am going to modify
the troublesome scripts in the $50k software and leave the security of
the OS intact. Thanks.
----
Actually, setting them to "1", is not "leaving the OS security intact" --
it's adding new, non-default security in Redhat and Suse distro's.
The default OS setting is 0 for those as it makes the way hard &
softlinks incompatible with past behavior. I ran into the
new settings when upgrading from SUSE 13.1 -> 13.2.
Many new "security pollution" problems are being introduced due to
people forgetting about how groups can be used to control access.
Various programs (ssh, sendmail, sudo, lilo, to name a few),
complain or fail, if you use groups to control access and try
allow access by group.
The new settings broke a use case where where I use permissions,
different UID's and hardlinks to save considerable space.
Case in point. I control access (*to myself*) in my linux source
trees. Under my linux-source dir, I have "unmodified" dirs for each
version of linux I've been working with. When a new version comes
out, I create a 2nd copy using 'cp -al', and, as root, apply the patch
necessary to create the new version. I.e. Currently I have source trees
going back to 3.10. Though I think I started with a new copy with
linux 4.0.
To upgrade to 4.0.2 or 4.0.4, I apply a patch to the 4.0 source tree
in a new directory.
This saves on disk space, as well as propagates local patches for my
build environment. Looking at "virgin" sources with "du" for some
4.0 derived source dirs:
du -sh linux-4.0{,.[0-9]}
638M linux-4.0
2.6M linux-4.0.0
14M linux-4.0.2
19M linux-4.0.4
Linux-4.0.2 and linux-4.0.4 share about 620M with the
linux-4.0 sources. The linux-4.0.0 is an exact copy of
the 4.0 tree with the "2.6M" being space used for the
duplication of the directories which "cp -al" creates
as new copies, owned by the user (so they can write in them!).
Between main-releases:
du -sh linux-4.[034]
638M linux-4.0
220M linux-4.3
231M linux-4.4
About 220-240M changes.
Looking at 4.4 derived trees, we see the stand-alone size of
the linux-4.4 dir:
du -sh linux-4.4{,.[13]}
699M linux-4.4
6.5M linux-4.4.1
17M linux-4.4.3
I.e. linux-4.4, by itself is 699M. But it shares over 400M with
linux-4.0.
To ensure I don't accidently change my "reference" sources,
the dirs are writable by the owner or the group, with files only
being writable by the owner:
llg -d linux-4.[034]
drwxrwsr-x 23 root root 4096 Aug 12 2015 linux-4.0/
drwxrwsr-x 24 root root 4096 Feb 1 21:42 linux-4.3/
drwxrwsr-x 24 root root 4096 Feb 1 21:52 linux-4.4/
To actually work & build, as non-root user, I do a "cp -al"
from the reference-dirs into work dirs, so du looks like:
du -sh linux-4.[034] ish-4[034]*
638M linux-4.0
396M linux-4.3
231M linux-4.4
3.0G ish-400
3.5G ish-400-nlnk
3.0G ish-402
3.0G ish-404
3.3M ish-43
3.2G ish-433
476M ish-441
440M ish-443
Note -- the "GB"-size dirs have object files in them. Ish-441 & Ish-443
likely had a make-clean done in them which leaves stuff. When I
copy them as a local user, the mode-bits get copied over to the
new tree, but where files are owned by root (if unchanged) or by
me (if changed). Pruned ls output:
llg ish-443
total 50876
-rw-r--r-- 99 root root 18693 Jan 19 2014 COPYING
-rw-r--r-- 7 root root 97181 Feb 1 21:41 CREDITS
drwxrwsr-x 112 lin root 8192 Feb 1 21:52 Documentation/
-rw-r--r-- 24 root root 2622 Sep 10 2015 Kbuild
-rw-rw-r-- 1 lin root 2943284 Feb 25 22:53 System.map
drwxrwsr-x 2 lin root 178 Feb 25 17:51 usr/
-rwxrwxr-x 1 lin root 24768740 Feb 25 22:53 vmlinux*
----
My script to download patches and create new 'linux' source
trees and then create a "work dir" for me, started failing
when I moved from SuSE 13.1->13.2, since SuSE copied Redhat's
new settings for the links.
The new setting prohibited me creating a links to root-owned
files -- even though I could read them, and was only creating
links in my user-owned directory.
I.e. the new protected links (at least for hard),
protect me from using the normal unix mode-bits and groups
to create secure, read-only copies of unmodified files in
my source tree.
The links (in the case of hardlinks) are not protected,
but the ability to create links to a common source was restricted
to root -- which would defeat my userid's ability to create a copy
of root's source tree that I could work in without duplicating
all the files.
The difference size for ~55 versions of the kernel is
==>> 6.2G linked, and 74G not linked.<<==
The hard-link protection doesn't give any added protection, but
does prevent getting easy protection using permissions & UID's
to disable accidental writes to "original sources".
Needless to say, on my systems, I don't modify those
settings from the OS's default.
On Thu, 2016-07-28 at 15:06 -0500, John McKown wrote:
On Thu, Jul 28, 2016 at 2:49 PM, László Házy <haz...@yahoo.com
<mailto:haz...@yahoo.com>> wrote:
[root]# cat /usr/lib/sysctl.d/50-default.conf | grep fs
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
You can change those parameters in the file. Or you can do a test by
doing:
sysctl -w fs.protected_hardlinks=0
sysctl -w fs.protected_symlinks=0
I guess this explains it. Problem is (my problem now) that it breaks
the startup scripts of a $50000 software, which does work on an
older FedoraCore. Is this a kernel problem then?
----
It's a "feature"! ;-)
On 28 Jul 2016, at 20:56, Charles Daffern wrote:
As far as I'm aware, the inability to use symlinks owned by
another user in a sticky directory is a security feature of some
kernels. It helps to prevent symlink attacks.
----
Some people think it does, but it only helps protect against
programs that had security flaws in them in the first place.
