[Buildd-tools-devel] Bug#476332: Bug#476332: schroot: Fails mysteriously when /etc/schroot/schroot.conf is a symlink

[Timothy G Abbott]

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