Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Reading from the spec: The solution is to permit symlinks to only be followed when outside a sticky world-writable directory, or when the uid of the symlink and follower match, or when the directory owner matches the symlink's owner. It was a bit unclear to me the first time I read it: I thought it was and, not or. So this is not as restrictive as I thought, and I'll withdraw my conerrn about this breaking linking /sbin/* or /us/sbin/* programs to $HOME//bin/. On Sun, Mar 24, 2013 at 9:19 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 24.03.2013 04:08, schrieb Kevin Kofler: Miloslav Trmač wrote: BTW determining this accurately should be fairly doable[1]. Just look for symlink() and link() calls (and recursively through wrapper APIs / language bindings). These syscalls are fairly rare. That checks for PROGRAMS which run into this. It catches neither admin's custom scripts nor ln commands run directly by the users. Who knows on how many machines manually created symlinks point to inodes owned by different users? maybe you guys should read what the protection does how many directories except /tmp are world-writeable and have STICKY bit? fs.protected_symlink symlinks to only be followed when outside a sticky world-writable directory fs.protected_hardlinks blocks hardlinks to other people's WORLD-READABLE files if you can't write to them -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Le dimanche 24 mars 2013 à 09:05 -0400, Nico Kadel-Garcia a écrit : On Sat, Mar 23, 2013 at 11:08 PM, Kevin Kofler kevin.kof...@chello.at wrote: Miloslav Trmač wrote: BTW determining this accurately should be fairly doable[1]. Just look for symlink() and link() calls (and recursively through wrapper APIs / language bindings). These syscalls are fairly rare. That checks for PROGRAMS which run into this. It catches neither admin's custom scripts nor ln commands run directly by the users. Who knows on how many machines manually created symlinks point to inodes owned by different users? For example, I've been known to link /sbin programs to $HOME/bin/. on hosts I use and do not have root access on, so that traceroute iour chkconfig or the hardlink program are always avaialble. The decision to leave /sbin out of the default PATH except for root users has created many interesting such situations. You can also just fix the path for your user. This is especially true in environments where commercial or experimental versions of gcc or Java are instlled in /usr/local/gcc or /usr/local/java or /opt/[package] on some hosts and not others, and need to be activated on a user-by-user basis. Unless your $HOME/bin is using a sticky bit and is world writable like /tmp, this will change nothing for you. See http://users.sosdg.org/~qiyong/lxr/source/Documentation/sysctl/fs.txt#L160 for more information. Also, for the record, Debian also enable it for the next stable release : http://womble.decadent.org.uk/blog/whats-in-the-linux-kernel-for-debian-70-wheezy-part-1.html ( along other interesting things, like disable autoloading for seldomly used network protocols ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Am 24.03.2013 04:08, schrieb Kevin Kofler: Miloslav Trmač wrote: BTW determining this accurately should be fairly doable[1]. Just look for symlink() and link() calls (and recursively through wrapper APIs / language bindings). These syscalls are fairly rare. That checks for PROGRAMS which run into this. It catches neither admin's custom scripts nor ln commands run directly by the users. Who knows on how many machines manually created symlinks point to inodes owned by different users? maybe you guys should read what the protection does how many directories except /tmp are world-writeable and have STICKY bit? fs.protected_symlink symlinks to only be followed when outside a sticky world-writable directory fs.protected_hardlinks blocks hardlinks to other people's WORLD-READABLE files if you can't write to them signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Miloslav Trmač wrote: BTW determining this accurately should be fairly doable[1]. Just look for symlink() and link() calls (and recursively through wrapper APIs / language bindings). These syscalls are fairly rare. That checks for PROGRAMS which run into this. It catches neither admin's custom scripts nor ln commands run directly by the users. Who knows on how many machines manually created symlinks point to inodes owned by different users? [1] Well, fairly doable when compared to the /tmp-on-tmpfs, which is just impossible. It's still man-weeks of work. Pragmatically speaking, It did not break Ubuntu is not a QA technique that makes me happy, but might be good enough anyway. Well, /tmp-on-tmpfs is just broken, disabled on my machines and should be reverted in Fedora ASAP. It is not a good example to follow (and neither is UsrMove, whose consequences we're still suffering, see the recent thread about RPM dependencies on binaries). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Sun, Mar 17, 2013 at 10:07 PM, Kevin Kofler kevin.kof...@chello.at wrote: Kees Cook wrote: AFD was a single specific program doing a very specific task and hardly represents an average workload. I remain extremely disappointed that the default-on state was reverted. Ubuntu has had this feature enabled for YEARS now, and it stopped quite a few exploits cold. Who knows what other applications this extremely surprising and incompatible change breaks? BTW determining this accurately should be fairly doable[1]. Just look for symlink() and link() calls (and recursively through wrapper APIs / language bindings). These syscalls are fairly rare. Mirek [1] Well, fairly doable when compared to the /tmp-on-tmpfs, which is just impossible. It's still man-weeks of work. Pragmatically speaking, It did not break Ubuntu is not a QA technique that makes me happy, but might be good enough anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
John Reiser wrote: It seems to me that the private /tmp feature of recent Fedora systems has removed a large percentage of the potential vulnerabilities here. If you cannot see anybody else's /tmp then you cannot create vulnerabilities in /tmp for them, and they cannot create vulnerabilities in /tmp for you. Unfortunately, private /tmp is only enabled by default in Fedora for select services and not for users, mainly because some programs (ab)use /tmp to do sockets to communicate between users. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Kees Cook wrote: AFD was a single specific program doing a very specific task and hardly represents an average workload. I remain extremely disappointed that the default-on state was reverted. Ubuntu has had this feature enabled for YEARS now, and it stopped quite a few exploits cold. Who knows what other applications this extremely surprising and incompatible change breaks? (IMHO, even private /tmp is a better solution. It's also an incompatible change, but at least it has semantics a normal user can understand, whereas your solution layers really complicated hidden rules on top of something as basic as file permissions.) I'm with Linus when he says Breaking applications is unacceptable. End of story. It's broken them. Get over it. We aren't ready to enable private /tmp for the same reason, so why is this hack any more acceptable? IMHO the initscripts change should be reverted and we should stick to Linus's defaults. He said no for a reason. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: My patch put it in /usr/lib/sysctl.d, just coming from systemd itself. We could possibly throw that file into initscripts if systemd doesn't want to make that change (though I think Lennart would have the same objection). The rest of the standard sysctl settings are in the file /usr/lib/sysctl.d/00-system.conf, which comes from initscripts. I see no reason to create another file, just to add a couple more defaults. Oh, sure. Totally fine with me too. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Fri, Mar 15, 2013 at 7:42 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: My patch put it in /usr/lib/sysctl.d, just coming from systemd itself. We could possibly throw that file into initscripts if systemd doesn't want to make that change (though I think Lennart would have the same objection). The rest of the standard sysctl settings are in the file /usr/lib/sysctl.d/00-system.conf, which comes from initscripts. I see no reason to create another file, just to add a couple more defaults. Oh, sure. Totally fine with me too. https://bugzilla.redhat.com/show_bug.cgi?id=922030 josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/15/2013 09:04 AM, Josh Boyer wrote: On Fri, Mar 15, 2013 at 7:42 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: My patch put it in /usr/lib/sysctl.d, just coming from systemd itself. We could possibly throw that file into initscripts if systemd doesn't want to make that change (though I think Lennart would have the same objection). The rest of the standard sysctl settings are in the file /usr/lib/sysctl.d/00-system.conf, which comes from initscripts. I see no reason to create another file, just to add a couple more defaults. Oh, sure. Totally fine with me too. https://bugzilla.redhat.com/show_bug.cgi?id=922030 josh I guess we could open a feature page for this for F20, or do we want to pull it into F19. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFDKOMACgkQrlYvE4MpobOUAQCgwWTKB5d+sB7n+n+vf9mYJ90I Do4AmgOxvV4R3UR3qAemRaU9uGIEN24H =wFhV -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Fri, Mar 15, 2013 at 9:57 AM, Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/15/2013 09:04 AM, Josh Boyer wrote: On Fri, Mar 15, 2013 at 7:42 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: My patch put it in /usr/lib/sysctl.d, just coming from systemd itself. We could possibly throw that file into initscripts if systemd doesn't want to make that change (though I think Lennart would have the same objection). The rest of the standard sysctl settings are in the file /usr/lib/sysctl.d/00-system.conf, which comes from initscripts. I see no reason to create another file, just to add a couple more defaults. Oh, sure. Totally fine with me too. https://bugzilla.redhat.com/show_bug.cgi?id=922030 josh I guess we could open a feature page for this for F20, or do we want to pull it into F19. I don't think this needs a feature page. I'd like to see it in F19. There's a case to be made for enabling it on the other releases too, but F19 is a good target to start with. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Once upon a time, Josh Boyer jwbo...@gmail.com said: I don't think this needs a feature page. I'd like to see it in F19. There's a case to be made for enabling it on the other releases too, but F19 is a good target to start with. I agree that it doesn't really need a feature page, but IMHO it should be in the release notes (this is something that could break existing programs). It _shouldn't_ be an issue, but I don't think it is a good idea to enable this on released versions. If it is going to be changed for F19, the change should land ASAP so any potential issues can be found during testing. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On 03/15/2013 10:52 AM, Chris Adams wrote: I agree that it doesn't really need a feature page, but IMHO it should be in the release notes (this is something that could break existing programs). Here you go https://fedoraproject.org/wiki/Documentation_Security_Beat Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Mar 15, 2013 10:13 AM, Rahul Sundaram methe...@gmail.com wrote: On 03/15/2013 10:52 AM, Chris Adams wrote: I agree that it doesn't really need a feature page, but IMHO it should be in the release notes (this is something that could break existing programs). Here you go https://fedoraproject.org/wiki/Documentation_Security_Beat Rahul -- That is an excellent explanation, thanks Rahul! --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 Here some more info for this apparent regression http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72bb9c4bfc955edfd415 Best -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/14/2013 04:09 AM, yersinia wrote: On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh dwa...@redhat.com mailto:dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 Here some more info for this apparent regression http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72bb9c4bfc955edfd415 Best Well I believe Ubunto has been using this feature for years and maybe we should consider turning it on via systemd or a unit file. The breakage of AFD is not a legitimate reason for Fedora to turn it off. Kees, could you explain how these restrictions would help secure Fedora and any potential side effects. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFBy+AACgkQrlYvE4MpobO0CQCdHilzfd1TjE1RAllQ1YsmXj43 jwIAn1KH7+Tbm+a9TBQdX5CN5vagjh8t =it6d -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote: Well I believe Ubunto has been using this feature for years and maybe we should consider turning it on via systemd or a unit file. The breakage of AFD is not a legitimate reason for Fedora to turn it off. Why not add an LSM call, security_follow_restricted_link()? Then you could ship this protection with SELinux policy, and even turn it off per-label if specific applications need the old behavior. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 I apologize for the ignorance - but what do these _do_. They block a non priv user from hardlinking/softlinking to files they don't own. ln /etc/shadow ~/myshadow The other descriptions of fs.protected_*links say that the protection applies to the lookup side when following a link, and not to the creation side when installing the link. So the potential vulnerabilities still can be created, but damage is averted at the last possible moment. It seems to me that the private /tmp feature of recent Fedora systems has removed a large percentage of the potential vulnerabilities here. If you cannot see anybody else's /tmp then you cannot create vulnerabilities in /tmp for them, and they cannot create vulnerabilities in /tmp for you. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Once upon a time, John Reiser jrei...@bitwagon.com said: The other descriptions of fs.protected_*links say that the protection applies to the lookup side when following a link, and not to the creation side when installing the link. So the potential vulnerabilities still can be created, but damage is averted at the last possible moment. That is for symlink protection I believe. There's no way to do any hardlink protection at lookup time. Basically, these are two very different things being lumped together, and they should be addressed individually. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/14/2013 10:08 AM, Casey Dahlin wrote: On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote: Well I believe Ubunto has been using this feature for years and maybe we should consider turning it on via systemd or a unit file. The breakage of AFD is not a legitimate reason for Fedora to turn it off. Why not add an LSM call, security_follow_restricted_link()? Then you could ship this protection with SELinux policy, and even turn it off per-label if specific applications need the old behavior. --CJD We already do, but this protection does protect unconfined_t and for those who would dare to disable SELinux. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFCFNQACgkQrlYvE4MpobN0nwCg4ynXq6hXwYzAJu1NUembARUm lCoAn37VntIVg7DUC2tEv9cDozKGC4IE =UC3e -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote: On 03/14/2013 04:09 AM, yersinia wrote: On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh dwa...@redhat.com mailto:dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 Here some more info for this apparent regression http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72bb9c4bfc955edfd415 Best Well I believe Ubunto has been using this feature for years and maybe we should consider turning it on via systemd or a unit file. The breakage of AFD is not a legitimate reason for Fedora to turn it off. Kees, could you explain how these restrictions would help secure Fedora and any potential side effects. AFD was a single specific program doing a very specific task and hardly represents an average workload. I remain extremely disappointed that the default-on state was reverted. Ubuntu has had this feature enabled for YEARS now, and it stopped quite a few exploits cold. Everything about these restrictions is described in detail in the commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7 I'm happy to answer any questions. -Kees -- Kees Cook@outflux.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, Mar 14, 2013 at 5:12 PM, Kees Cook k...@outflux.net wrote: On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote: On 03/14/2013 04:09 AM, yersinia wrote: On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh dwa...@redhat.com mailto:dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 Here some more info for this apparent regression http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72bb9c4bfc955edfd415 Best Well I believe Ubunto has been using this feature for years and maybe we should consider turning it on via systemd or a unit file. The breakage of AFD is not a legitimate reason for Fedora to turn it off. Kees, could you explain how these restrictions would help secure Fedora and any potential side effects. AFD was a single specific program doing a very specific task and hardly represents an average workload. I remain extremely disappointed that the default-on state was reverted. Ubuntu has had this feature enabled for YEARS now, and it stopped quite a few exploits cold. Everything about these restrictions is described in detail in the commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7 I'm happy to answer any questions. Something like this patch to systemd should work, no? From 9ee10b11d0d13554d3c59205389d6ebf665a213a Mon Sep 17 00:00:00 2001 From: Josh Boyer jwbo...@redhat.com Date: Thu, 14 Mar 2013 18:30:47 -0400 Subject: [PATCH] Turn on protected hard and soft link protection by default --- Makefile.am | 9 +++-- sysctl.d/protected_links.conf.in | 11 +++ 2 files changed, 18 insertions(+), 2 deletions(-) create mode 100644 sysctl.d/protected_links.conf.in diff --git a/Makefile.am b/Makefile.am index 175d14b..68b5de9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2688,6 +2688,9 @@ pkgconfiglib_DATA += \ dist_catalog_DATA = \ catalog/systemd.catalog +sysctl_DATA = \ + sysctl.d/protected_links.conf + SOCKETS_TARGET_WANTS += \ systemd-journald.socket SYSINIT_TARGET_WANTS += \ @@ -2699,10 +2702,12 @@ EXTRA_DIST += \ src/journal/libsystemd-journal.sym \ units/systemd-journald.service.in \ units/systemd-journal-flush.service.in \ - src/journal/journald-gperf.gperf + src/journal/journald-gperf.gperf \ + sysctl.d/protected_links.conf.in CLEANFILES += \ - src/journal/journald-gperf.c + src/journal/journald-gperf.c \ + sysctl.d/protected_links.conf # -- if HAVE_MICROHTTPD diff --git a/sysctl.d/protected_links.conf.in b/sysctl.d/protected_links.conf.in new file mode 100644 index 000..f183b08 --- /dev/null +++ b/sysctl.d/protected_links.conf.in @@ -0,0 +1,11 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +# See sysctl.d(5) for for details. + +fs.protected_hardlinks=1 +fs.protected_symlinks=1 -- 1.8.1.2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
binKWT8x6c21S.bin Description: application/pgp-encrypted msg.asc Description: Binary data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Ok, apparently Mutt is a bit stupider than I thought. Let's try this again. On Thu, Mar 14, 2013 at 02:20:04PM -0400, Daniel J Walsh wrote: We already do, Good. but this protection does protect unconfined_t and for those who Maybe we're ready to except a confined user by default. Something very, very loose. would dare to disable SELinux. To hell with 'em. :) --CJD pgp0irRYb1paA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, 14.03.13 18:32, Josh Boyer (jwbo...@gmail.com) wrote: Everything about these restrictions is described in detail in the commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7 I'm happy to answer any questions. Something like this patch to systemd should work, no? Hmm, I'd very much prefer if the defaults are built into the kernel, and that sysctl in userspace is then used only by the admin to override these defaults, so that by default we ship with empty sysctl.d/ dirs. So, before I merge anything like this into systemd, why can't the kernel default setting simply be flipped? +fs.protected_hardlinks=1 +fs.protected_symlinks=1 Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Once upon a time, Lennart Poettering mzerq...@0pointer.de said: Hmm, I'd very much prefer if the defaults are built into the kernel, and that sysctl in userspace is then used only by the admin to override these defaults, so that by default we ship with empty sysctl.d/ dirs. So, before I merge anything like this into systemd, why can't the kernel default setting simply be flipped? Upstream kernel said no, distros can do it in userspace, and Fedora aims to remain true to upstream. Also, if upstream kernel does one thing and Fedora kernel the opposite, users would have unexpected defaults changing if they built their own kernel for some reason. Why would this need to be merged into systemd? Why not just sysctl.conf (or I guess the new-and-improved /usr/lib/sysctl.d/00-system.conf, which comes from initscripts)? As is pointed out (IIRC in the commit that reverted the default), if you can't trust the boot environment, you are already hosed. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, Mar 14, 2013 at 8:22 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 14.03.13 18:32, Josh Boyer (jwbo...@gmail.com) wrote: Everything about these restrictions is described in detail in the commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7 I'm happy to answer any questions. Something like this patch to systemd should work, no? Hmm, I'd very much prefer if the defaults are built into the kernel, and that sysctl in userspace is then used only by the admin to override these defaults, so that by default we ship with empty sysctl.d/ dirs. So, before I merge anything like this into systemd, why can't the kernel default setting simply be flipped? It would be yet another out-of-tree patch to carry along forever in Fedora. Or at best we try and upstream the default as a config setting but I'm not sure Linus would bite on that given his commit message when he switched the default to disabled. I'd rather avoid carrying a patch that has no chance of upstream when it can be done by a unit file or systemd itself. That's why they're settable from userspace to begin with. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, Mar 14, 2013 at 8:28 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: Hmm, I'd very much prefer if the defaults are built into the kernel, and that sysctl in userspace is then used only by the admin to override these defaults, so that by default we ship with empty sysctl.d/ dirs. So, before I merge anything like this into systemd, why can't the kernel default setting simply be flipped? Upstream kernel said no, distros can do it in userspace, and Fedora aims to remain true to upstream. Also, if upstream kernel does one thing and Fedora kernel the opposite, users would have unexpected defaults changing if they built their own kernel for some reason. Why would this need to be merged into systemd? Why not just sysctl.conf (or I guess the new-and-improved /usr/lib/sysctl.d/00-system.conf, which comes from initscripts)? My patch put it in /usr/lib/sysctl.d, just coming from systemd itself. We could possibly throw that file into initscripts if systemd doesn't want to make that change (though I think Lennart would have the same objection). josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, Mar 14, 2013 at 8:28 PM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Mar 14, 2013 at 8:22 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 14.03.13 18:32, Josh Boyer (jwbo...@gmail.com) wrote: Everything about these restrictions is described in detail in the commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7 I'm happy to answer any questions. Something like this patch to systemd should work, no? Hmm, I'd very much prefer if the defaults are built into the kernel, and that sysctl in userspace is then used only by the admin to override these defaults, so that by default we ship with empty sysctl.d/ dirs. So, before I merge anything like this into systemd, why can't the kernel default setting simply be flipped? It would be yet another out-of-tree patch to carry along forever in Fedora. Or at best we try and upstream the default as a config setting but I'm not sure Linus would bite on that given his commit message when he switched the default to disabled. I'd rather avoid carrying a patch that has no chance of upstream when it can be done by a unit file or systemd itself. That's why they're settable from userspace to begin with. Oh, right. Kees already tried the config option route: http://thread.gmane.org/gmane.linux.kernel/1383391/focus=1383496 Failed. So, back to carry a patch in the kernel forever, which I'd really like to avoid. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Once upon a time, Josh Boyer jwbo...@gmail.com said: My patch put it in /usr/lib/sysctl.d, just coming from systemd itself. We could possibly throw that file into initscripts if systemd doesn't want to make that change (though I think Lennart would have the same objection). The rest of the standard sysctl settings are in the file /usr/lib/sysctl.d/00-system.conf, which comes from initscripts. I see no reason to create another file, just to add a couple more defaults. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFAyvUACgkQrlYvE4MpobPhWQCfQaoeQVYAIT9CkTKA9h/u/+M8 ZL4An0sLjnYuWnhoclsvCCxP/SBrZGws =WQjN -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 13 Mar 2013 14:52:37 -0400 Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 I apologize for the ignorance - but what do these _do_. (please don't say they protect your hardlinks and symlinks) - I mean what does 'protected' mean in this context. thanks, - -sv -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iD8DBQFRQMvB1Aj3x2mIbMcRAq1sAJ93c0UxBsYkkjD/vOA4mlDV+x854ACfdeF0 L0XiZMhSMEV546f2616NGBM= =kxi7 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Wed, Mar 13, 2013 at 02:55:58PM -0400, seth vidal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 13 Mar 2013 14:52:37 -0400 Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 I apologize for the ignorance - but what do these _do_. (please don't say they protect your hardlinks and symlinks) - I mean what does 'protected' mean in this context. See: http://lwn.net/Articles/503660/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Once upon a time, seth vidal skvi...@fedoraproject.org said: On Wed, 13 Mar 2013 14:52:37 -0400 Daniel J Walsh dwa...@redhat.com wrote: sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 I apologize for the ignorance - but what do these _do_. (please don't say they protect your hardlinks and symlinks) - I mean what does 'protected' mean in this context. I remember when these were discussed on linux-kernel, and I thought they had some fairly small use cases (not really intended for a general purpose system). However, that's been a while, so off to Google... https://lwn.net/Articles/503660/ The symlink bit stops following of symlinks in sticky, world-writable directories, except when the UID of the symlink and process match, or when the UID of the symlink and the directory match. So, user 123 could create a symlink in /tmp and follow it (but nobody else could), or root could create a symlink in /tmp that everybody could follow. I didn't find a detailed description of the hardlink protection right off, however it did apparently break existing programs, so it was disabled by default. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/13/2013 02:55 PM, seth vidal wrote: On Wed, 13 Mar 2013 14:52:37 -0400 Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 I apologize for the ignorance - but what do these _do_. (please don't say they protect your hardlinks and symlinks) - I mean what does 'protected' mean in this context. thanks, -sv They block a non priv user from hardlinking/softlinking to files they don't own. ln /etc/shadow ~/myshadow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFAzLQACgkQrlYvE4MpobNe7ACePSXtDJP5dZzgcVk6gma0HOis ZJEAnjRO9qcsiIeCriJOAaKku2UrQCWq =dp1F -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Wed, Mar 13, 2013 at 2:55 PM, seth vidal skvi...@fedoraproject.org wrote: I apologize for the ignorance - but what do these _do_. (please don't say they protect your hardlinks and symlinks) - I mean what does 'protected' mean in this context. It's an fs-level implementation of Apache's SymlinksIfOwnerMatch. It closes a number of vulnerabilities, such as taking advantages of insecure tempfile handling (you think you're writing to /tmp/myapp.debug, but a malicious symlink points that to /etc/somethingoranother). I agree that we should turn this on by default. Best, -- Konstantin Ryabitsev LinuxFoundation.org Montréal, Québec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
