Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?

[Nico Kadel-Garcia]

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  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?

[Reindl Harald]

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?

[Michael Scherer]

Le dimanche 24 mars 2013 à 09:05 -0400, Nico Kadel-Garcia a écrit :
> On Sat, Mar 23, 2013 at 11:08 PM, Kevin Kofler  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?

[Nico Kadel-Garcia]

On Sat, Mar 23, 2013 at 11:08 PM, Kevin Kofler  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. 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.

>> [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).

Amen.
-- 
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?

[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?

> [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?

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/20/2013 09:49 PM, Kees Cook wrote:
> On Sun, Mar 17, 2013 at 10:07:48PM +0100, Kevin Kofler 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? (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.
> 
> https://lwn.net/Articles/543273/ "On a vanilla kernel, protected_hardlinks
> unfortunately has the default value zero" That's what Linus's defaults get:
> vulnerable-by-default.
> 
> Specialized applications are the exception, and if you use them, it's your 
> responsibility to tune your system as needed. Why leave your system 
> vulnerable to script-kiddie attacks by default?
> 
> The semantics of both world-writable sticky directories and hardlink access
> are undefined by POSIX. This fix was not a "hack", it corrects a bad
> decision made over a decade ago that was overwhelming more commonly used
> for vulnerability exploitation purposes.
> 
> -Kees
> 
I agree, we make lots of decisions in the OS that have the ability to break
applications by default.  FireWall, SELinux, Services disabled by default, not
allowing tons of setuid apps, other settings like mmap_zero.

If we do not secure the machine by default then no users, especially naive
users will turn on these protections.

Linus has different requirements for the kernel, but leaves it up to the
distributions to configure the kernel.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFLCGQACgkQrlYvE4MpobOuqQCgyX7uHmRCo8HzSEiVLrKXggbL
UX4An3hrqSLprTbv2zcEYmZ0dUh3SphI
=1WRB
-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?

[Kees Cook]

On Sun, Mar 17, 2013 at 10:07:48PM +0100, Kevin Kofler 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? (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.

https://lwn.net/Articles/543273/
"On a vanilla kernel, protected_hardlinks unfortunately has the default
value zero" That's what Linus's defaults get: vulnerable-by-default.

Specialized applications are the exception, and if you use them, it's your
responsibility to tune your system as needed. Why leave your system
vulnerable to script-kiddie attacks by default?

The semantics of both world-writable sticky directories and hardlink
access are undefined by POSIX. This fix was not a "hack", it corrects a
bad decision made over a decade ago that was overwhelming more commonly
used for vulnerability exploitation purposes.

-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?

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/15/2013 11:11 AM, Rahul Sundaram 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
I a not sure private tmp for allowed would solve this problem,  since you
could still attempt to trick a setuid app to read a link.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFJs/QACgkQrlYvE4MpobNh9QCfaxkpmf4oFnTVlpgJ1IDzMM+S
mu4AnitJ5/d9NCm/RfBtYcAiRioaU3fU
=TiHs
-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?

[Miloslav Trmač]

On Sun, Mar 17, 2013 at 10:07 PM, Kevin Kofler  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?

[Kevin Kofler]

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?

[Kevin Kofler]

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?

[Pete Travis]

On Mar 15, 2013 10:13 AM, "Rahul Sundaram"  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?

[Rahul Sundaram]

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?

[Chris Adams]

Once upon a time, Josh Boyer  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 
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?

[Josh Boyer]

On Fri, Mar 15, 2013 at 9:57 AM, Daniel J Walsh  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  wrote:
>>> On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams  wrote:
 Once upon a time, Josh Boyer  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?

[Daniel J Walsh]

-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  wrote:
>> On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams  wrote:
>>> Once upon a time, Josh Boyer  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?

[Josh Boyer]

On Fri, Mar 15, 2013 at 7:42 AM, Josh Boyer  wrote:
> On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams  wrote:
>> Once upon a time, Josh Boyer  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?

[Josh Boyer]

On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams  wrote:
> Once upon a time, Josh Boyer  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?

[Chris Adams]

Once upon a time, Josh Boyer  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 
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?

[Josh Boyer]

On Thu, Mar 14, 2013 at 8:28 PM, Josh Boyer  wrote:
> On Thu, Mar 14, 2013 at 8:22 PM, Lennart Poettering
>  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?

[Josh Boyer]

On Thu, Mar 14, 2013 at 8:28 PM, Chris Adams  wrote:
> Once upon a time, Lennart Poettering  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?

[Josh Boyer]

On Thu, Mar 14, 2013 at 8:22 PM, Lennart Poettering
 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?

[Chris Adams]

Once upon a time, Lennart Poettering  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 
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?

[Lennart Poettering]

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?

[Casey Dahlin]

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?

[Casey Dahlin]

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?

[Josh Boyer]

On Thu, Mar 14, 2013 at 5:12 PM, Kees Cook  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 > > > 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 
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?

[Kees Cook]

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  > > 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?

[Daniel J Walsh]

-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?

[Chris Adams]

Once upon a time, John Reiser  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 
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?

[John Reiser]

>>> 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?

[Casey Dahlin]

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?

[Daniel J Walsh]

-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  > 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?

[yersinia]

On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh  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?

[Konstantin Ryabitsev]

On Wed, Mar 13, 2013 at 2:55 PM, seth vidal  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

Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?

[Daniel J Walsh]

-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 
> 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?

[Chris Adams]

Once upon a time, seth vidal  said:
> On Wed, 13 Mar 2013 14:52:37 -0400
> Daniel J Walsh  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 
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?

[Richard W.M. Jones]

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  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?

[seth vidal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 13 Mar 2013 14:52:37 -0400
Daniel J Walsh  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

Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?

[Daniel J Walsh]

-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