[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: change in OS defaults (was: bug in [ -f file ] test)

From: Linda Walsh
Subject: Re: change in OS defaults (was: bug in [ -f file ] test)
Date: Sun, 31 Jul 2016 18:31:14 -0700
User-agent: Thunderbird

� 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

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 <address@hidden <mailto:address@hidden>> 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

[Prev in Thread] Current Thread [Next in Thread]