[Buildd-tools-devel] Bug#476332: Bug#476332: schroot: Fails mysteriously when /etc/schroot/schroot.conf is a symlink
Timothy G Abbott
tabbott at MIT.EDU
Thu Apr 17 08:10:55 UTC 2008
The discussion of O_NOFOLLOW in the following might be helpful:
http://www.linux-knowledge-portal.org/en/content.php?&content/programming/secprog2.html
Most attacks that O_NOFOLLOW prevents can be executed with hard links; I
believe the only exceptions are those in which the object being opened is
a directory or other object that cannot be hard linked, and only then when
the symlink is in the last component of the directory name.
Consequently, I believe O_NOFOLLOW is intended for programs like find, and
is not useful for much else.
Correct me if I'm wrong, but I believe schroot only reads configuration
files from within /etc/, so it should not be vulnerable to the typical
race condition attacks that O_NOFOLLOW is trying to prevent.
-Tim Abbott
On Wed, 16 Apr 2008, Roger Leigh wrote:
> On Tue, Apr 15, 2008 at 06:41:31PM -0400, Timothy G Abbott wrote:
>> Package: schroot
>> Version: 1.1.6-1
>> Severity: normal
>>
>> When I try to use schroot on a system where /etc/schroot/schroot.conf is a
>> symbolic link to another file (I've triple-checked that it's a regular
>> file and not another symlink), I get the following strange error:
>>
>> $ schroot -pc athena
>> E: /etc/schroot/schroot.conf: Failed to open file: Too many levels of symbolic links
>>
>> There's only one symbolic link involved, and the normal limit for
>> recursive symbolic links on linux is much higher than that.
>
> The standard errors (from the source code) are:
>
> FILE_NOTREG, "File is not a regular file"
> FILE_OPEN, "Failed to open file"
> FILE_OWNER, "File is not owned by user root"
> FILE_PERMS, "File has write permissions for others"))
>
> Due to running setuid-root, I do some extra checks to ensure that the
> system can't be compromised if the permissions are wrong. One
> additional step we take is here:
>
> // stat filename (in case it's a pipe and open(2) blocks)
> stat file_status1(file);
> if (file_status1.uid() != 0)
> throw error(file, FILE_OWNER);
> if (file_status1.check_mode(stat::PERM_OTHER_WRITE))
> throw error(file, FILE_PERMS);
> if (!file_status1.is_regular())
> throw error(file, FILE_NOTREG);
>
> /* Use a UNIX fd, for security (no races) */
> int fd = open(file.c_str(), O_RDONLY|O_NOFOLLOW);
> if (fd < 0)
> throw error(file, FILE_OPEN, strerror(errno));
>
> Your errror is from the last line. We deliberately instructed open(2)
> to not follow symbolic links with the O_NOFOLLOW, which is why you get
> the rather cryptic error about "too many levels of symbolic links"--
> one level or greater is too much in this case.
>
> I chose to do this for security reasons, but this could be changed by
> removing the O_NOFOLLOW. I would, however, need to be convinced that
> this was no less secure than with the O_NOFOLLOW before changing this
> --I don't want to unintentionally introduce a security exploit, so I
> chose the convervative option originally.
>
>
> Regards,
> Roger
>
> --
> .''`. Roger Leigh
> : :' : Debian GNU/Linux http://people.debian.org/~rleigh/
> `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
> `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
>
More information about the Buildd-tools-devel
mailing list