� 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.


Reply via email to