Re: Failed clisp-2.49.93+ in FreeBSD
Pascal Bourguignon <[email protected]> Mon, 25 Mar 2019 20:44:58 +0100
| Newsgroups | gmane.lisp.clisp.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============8334889505570304930== Content-Type: multipart/alternative; boundary="Apple-Mail=_4BACD3AF-BE86-407E-96DA-9505EE5FB41A" --Apple-Mail=_4BACD3AF-BE86-407E-96DA-9505EE5FB41A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25 Mar 2019, at 15:28, Don Cohen = <[email protected]> wrote: >=20 > [email protected] writes: >=20 >> - During configuration, compilation & build NOTHING should require >> root access. >=20 > I'm not sure how to interpret "should" or "build" in that sentence. > I'd include running the tests as part of build, and I recall a few > tests that do require root in order to pass. =20 > (One that comes to mind is creating raw sockets.) >=20 >> Generally, you configure and build SW as a low-privilege user, best >> inside a jail, >=20 > So if the entire process were inside a chroot or vm or container > you wouldn't mind root access, right? Perhaps this would be a > good way to at least run the tests above. >=20 >> so the poor configuration scripts can't destroy your system >> inadvertently. Once that is over, you install, i.e. copy few >> selected files to privileged locations as root. >=20 > It's interesting that we're supposed to trust the software that > was built from the scripts that we're not supposed to trust. > I do get your point that the configuration scripts are likely > to be written with less attention than the code intended to run > in the built system. This suggests that someone who actually=20 > wants to plant malware into a system should concentrate on the=20 > configuration scripts. >=20 > I suppose the testing code falls somewhere between the configuration > script code and the code intended to run in the built system in terms > of attention. If that testing code has to run as root, that would > make it a good target as well. >=20 > I suppose you'd recommend never running lisp as root. =20 > (It turns out I do that all the time.) =20 > For that matter, you probably don't recommend running anything else > as root (which I also do all the time). > Perhaps this view makes more sense in the case where a single machine > is shared by many users who all rely on it - the common case before > computers became "personal" (starting about 40 years ago). Yes. You can run system processes under system accounts. Only a few programs need to be started as root, but they will fallback = to a user account as soon as they=E2=80=99re done initializing (eg. = listening on a reserved port). > Many of the machines I use now have users other than root only because > they were created by default. I think in at least one case that > user has only ever been used to do one thing: build clisp because > the script doesn't want to run as root! You could do that when computed didn=E2=80=99t have interfaces to the = exterior world. When you typed each byte of all the programs you ran on your computer. But as soon as you started to load programs coming from somewhere else = (eg. as punched cards or magnetic tapes), and much more when the = computer is connected to the internet, you cannot trust the code = anymore. You would have to audit all the sources, and all the compiler binaries! see: http://cm.bell-labs.com/ who/ken/trust.html and: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf = <https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf> --=20 __Pascal J. Bourguignon__ --Apple-Mail=_4BACD3AF-BE86-407E-96DA-9505EE5FB41A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On 25 Mar 2019, at 15:28, Don Cohen <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D""><a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a> writes:<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D""> - During configuration, = compilation & build NOTHING should require<br class=3D""> root = access.<br class=3D""></blockquote><br class=3D"">I'm not sure how to = interpret "should" or "build" in that sentence.<br class=3D"">I'd = include running the tests as part of build, and I recall a few<br = class=3D"">tests that do require root in order to pass. <br = class=3D"">(One that comes to mind is creating raw sockets.)<br = class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">Generally, = you configure and build SW as a low-privilege user, best<br = class=3D"">inside a jail,<br class=3D""></blockquote><br class=3D"">So = if the entire process were inside a chroot or vm or container<br = class=3D"">you wouldn't mind root access, right? Perhaps this = would be a<br class=3D"">good way to at least run the tests above.<br = class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">so the = poor configuration scripts can't destroy your system<br = class=3D"">inadvertently. Once that is over, you install, i.e. = copy few<br class=3D"">selected files to privileged locations as = root.<br class=3D""></blockquote><br class=3D"">It's interesting that = we're supposed to trust the software that<br class=3D"">was built from = the scripts that we're not supposed to trust.<br class=3D"">I do get = your point that the configuration scripts are likely<br class=3D"">to be = written with less attention than the code intended to run<br class=3D"">in= the built system. This suggests that someone who actually <br = class=3D"">wants to plant malware into a system should concentrate on = the <br class=3D"">configuration scripts.<br class=3D""><br class=3D"">I = suppose the testing code falls somewhere between the configuration<br = class=3D"">script code and the code intended to run in the built system = in terms<br class=3D"">of attention. If that testing code has to = run as root, that would<br class=3D"">make it a good target as well.<br = class=3D""><br class=3D"">I suppose you'd recommend never running lisp = as root. <br class=3D"">(It turns out I do that all the time.) = <br class=3D"">For that matter, you probably don't recommend = running anything else<br class=3D"">as root (which I also do all the = time).<br class=3D"">Perhaps this view makes more sense in the case = where a single machine<br class=3D"">is shared by many users who all = rely on it - the common case before<br class=3D"">computers became = "personal" (starting about 40 years ago).<br = class=3D""></div></div></blockquote><div><br class=3D""></div>Yes. You = can run system processes under system accounts.</div><div>Only a few = programs need to be started as root, but they will fallback to a user = account as soon as they=E2=80=99re done initializing (eg. listening on a = reserved port).</div><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div class=3D"">Many of the machines I use = now have users other than root only because<br class=3D"">they were = created by default. I think in at least one case that<br = class=3D"">user has only ever been used to do one thing: build clisp = because<br class=3D"">the script doesn't want to run as root!<br = class=3D""></div></div></blockquote><br class=3D""></div><div><br = class=3D""></div><div>You could do that when computed didn=E2=80=99t = have interfaces to the exterior world.</div><div>When you typed each = byte of all the programs you ran on your computer.</div><div>But as soon = as you started to load programs coming from somewhere else (eg. as = punched cards or magnetic tapes), and much more when the computer is = connected to the internet, you cannot trust the code = anymore.</div><div>You would have to audit all the sources, and all the = compiler binaries!</div><div>see: <span style=3D"caret-color: = rgb(84, 84, 84); background-color: rgb(255, 255, 255);" class=3D""><a = href=3D"http://cm.bell-labs.com/" class=3D"">http://cm.bell-labs.com/</a> = who/ken/trust.html</span></div><font color=3D"#000000" class=3D""><div = class=3D"TbwUpd" style=3D"cursor: pointer; text-decoration: none; = display: inline-block; line-height: 1.54; padding-bottom: 1px; = padding-top: 1px;"><cite class=3D"iUh30" style=3D"font-style: normal; = padding-top: 1px; line-height: 1.43;">and: <a = href=3D"https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pd= f" = class=3D"">https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson= .pdf</a></cite></div></font><div class=3D""><br class=3D""></div><div = class=3D""><div class=3D""><div class=3D""> <div style=3D"letter-spacing: normal; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div = style=3D"letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div = style=3D"letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" = class=3D"">-- <br class=3D"">__Pascal J. Bourguignon__</div><div = style=3D"letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><br class=3D""><br class=3D""></div></div></div> </div> <br class=3D""></div></div></body></html>= --Apple-Mail=_4BACD3AF-BE86-407E-96DA-9505EE5FB41A-- --===============8334889505570304930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============8334889505570304930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ clisp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/clisp-devel --===============8334889505570304930==--