[PATCH] classes/sanity: check for suid root command evility

[PATCH] classes/sanity: check for suid root command evility

[Paul Eggleton]

Some users have been found to have an unnamed third-party piece of
software installed which sets chmod, chown and mknod as suid root as
part of its installation process. This interferes with the operation of
pseudo and can result in files really being owned by root within the
build output, and therefore breaks the build, apart from being a
security issue. Check for this and bail out early if it is found.

Reported-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/sanity.bbclass | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index a505a5d..0546293 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -569,6 +569,16 @@ def check_sanity_everybuild(status, d):
     if 0 == os.getuid():
         raise_sanity_error("Do not use Bitbake as root.", d)
 
+    # Some third-party software apparently relies on chmod etc. being suid root (!!)
+    import stat
+    suid_check_bins = "chown chmod mknod".split()
+    for bin_cmd in suid_check_bins:
+        bin_path = bb.utils.which(os.environ["PATH"], bin_cmd)
+        if bin_path:
+            bin_stat = os.stat(bin_path)
+            if bin_stat.st_uid == 0 and bin_stat.st_mode & stat.S_ISUID:
+                status.addresult('%s has the setuid bit set. This interferes with pseudo and may cause other issues that break the build process.\n' % bin_path)
+
     # Check the Python version, we now have a minimum of Python 2.7.3
     import sys
     if sys.hexversion < 0x020703F0:
-- 
1.8.1.2

Re: [PATCH] classes/sanity: check for suid root command evility

[Mark Hatle]

On 7/26/13 5:48 AM, Paul Eggleton wrote:
> Some users have been found to have an unnamed third-party piece of
> software installed which sets chmod, chown and mknod as suid root as
> part of its installation process. This interferes with the operation of
> pseudo and can result in files really being owned by root within the
> build output, and therefore breaks the build, apart from being a
> security issue. Check for this and bail out early if it is found.
>
> Reported-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
>
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>

Should these items be added to the buildtools-tarball target?  It might help 
avoid the problem in the same way we already do to detect the bad make, tar, etc..

--Mark

> ---
>   meta/classes/sanity.bbclass | 10 ++++++++++
>   1 file changed, 10 insertions(+)
>
> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> index a505a5d..0546293 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -569,6 +569,16 @@ def check_sanity_everybuild(status, d):
>       if 0 == os.getuid():
>           raise_sanity_error("Do not use Bitbake as root.", d)
>
> +    # Some third-party software apparently relies on chmod etc. being suid root (!!)
> +    import stat
> +    suid_check_bins = "chown chmod mknod".split()
> +    for bin_cmd in suid_check_bins:
> +        bin_path = bb.utils.which(os.environ["PATH"], bin_cmd)
> +        if bin_path:
> +            bin_stat = os.stat(bin_path)
> +            if bin_stat.st_uid == 0 and bin_stat.st_mode & stat.S_ISUID:
> +                status.addresult('%s has the setuid bit set. This interferes with pseudo and may cause other issues that break the build process.\n' % bin_path)
> +
>       # Check the Python version, we now have a minimum of Python 2.7.3
>       import sys
>       if sys.hexversion < 0x020703F0:
>

Re: [PATCH] classes/sanity: check for suid root command evility

[Paul Eggleton]

On Monday 29 July 2013 18:43:32 Mark Hatle wrote:
> On 7/26/13 5:48 AM, Paul Eggleton wrote:
> > Some users have been found to have an unnamed third-party piece of
> > software installed which sets chmod, chown and mknod as suid root as
> > part of its installation process. This interferes with the operation of
> > pseudo and can result in files really being owned by root within the
> > build output, and therefore breaks the build, apart from being a
> > security issue. Check for this and bail out early if it is found.
> > 
> > Reported-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
> > 
> > Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> 
> Should these items be added to the buildtools-tarball target?  It might help
> avoid the problem in the same way we already do to detect the bad make,
> tar, etc..

To be honest I'd rather not try to work around misconfiguration such as this.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre