Re: mount(8) security and symlink(7)
errata: > Date: Sat, 26 Jun 2021 02:03:18 +1000 (+1000) > From: Reuben ua Bríġ > after learning that OpenSTMP had used sytem(3) rather than execv(3) > resulting in a bug reminiscent of the morris-worm i had guessed it was system(3), but having now seen the advisory: https://lwn.net/Articles/810882/ apparently it was really exec sh -c; kinky! people, people, people, is it so hard to write a shell script to exec? do you really need that disgusting shell syntax everywhere? p.s. are the any plans to ports antiwank to openbsd?
Re: Localization of date(1) and XFCE
Thank you for the detailed answer. I'll use this information to talk to xfce devs and the maintainer if they could do anything to keep a consistent experience in OpenBSD. El June 25, 2021 5:28:00 PM UTC, Ingo Schwarze escribió: >Hi, > >Jan Stary wrote on Tue, Jun 22, 2021 at 11:24:15AM +0200: >> On Jun 20 18:58:31, ffuen...@texto-plano.xyz wrote: > >>> I speak Spanish and thus I use a locale called es_CL.UTF-8. XFCE is >fine >>> with it. However, my date is expressed directly as it comes from >date(1). >>> This is confirmed by their docs >>> https://docs.xfce.org/xfce/xfce4-panel/4.16/clock so how do I make >date to >>> work with my language. >>> >>> This is my locale: >>> >>> LANG=es_CL.UTF-8 >>> LC_COLLATE="es_CL.UTF-8" >>> LC_CTYPE="es_CL.UTF-8" >>> LC_MONETARY="es_CL.UTF-8" >>> LC_NUMERIC="es_CL.UTF-8" >>> LC_TIME="es_CL.UTF-8" >>> LC_MESSAGES="es_CL.UTF-8" >>> LC_ALL=es_CL.UTF-8 > >> man locale >> >> Programs in the OpenBSD base system ignore the locale except >> for the character encoding, and it is not recommended to >> use any of these variables except that the following >> non-default setting is supported as an option: >> >> export LC_CTYPE=en_US.UTF-8 >> >> OpenBSD's date(1) ignores your locale setting. > >That's the correct answer, and there are no plans to change that in >the future. > >The reason is that we prioritize simplicity and maintainablity >of the C library, and consequently correctness and security, >over localization of base system facilities. On top of that, >even if you do not take the horrible complication of the library >code that LC_* support would imply into account, LC_* also poses >some security risks from the user perspective, in particular in >system administration and maintenance contexts. Predicatbility >of output, and consistent parsing of input, is more valuable for >low-level work than localization. > >Perspectives may vary, but my personal opinion is that adding all >those LC_* variables to POSIX was a mistake. The C library is >not a reasonable place to handle higly specialized and highly >complicated topics like localization. They belong into >specialized programs like typesettung software, UI libraries >and the like, not into a general-purpose operating system. > >In general, we try to follow POSIX because standardization and >portability have significant advantages. But there are limits. >If standards requirements are too bad, we may decide to ignore >them in some (rare) cases. Hence, on OpenBSD, you can rely on >predictable output from strftime(3) and on predictable parsing >by strptime(3). > >All this is mostly documented, for example: > > STRFTIME(3)Library Functions Manual > [...] > CAVEATS > On systems other than OpenBSD, the LC_TIME locale(1) category can > cause erratic output; see CAVEATS in setlocale(3) for details. > > SETLOCALE(3) Library Functions Manual > [...] > CAVEATS > On systems other than OpenBSD, calling setlocale() or uselocale(3) > with a category other than LC_CTYPE can cause erratic behaviour > of many library functions. For security reasons, make sure > that portable programs only use LC_CTYPE. > > For example, the following functions may be affected. The > list is probably incomplete. For example, additional library > functions may be impacted if they directly or indirectly call > affected functions, or if they attempt to imitate aspects of > their behaviour. Functions that are not standardized may be > affected too. > > LC_COLLATE > glob(3), strcoll(3), strxfrm(3), wcscoll(3), wcsxfrm(3), > and the functions documented in regexec(3) > > LC_MESSAGES > catgets(3), catopen(3), nl_langinfo(3), perror(3), > psignal(3), strerror(3), strsignal(3), and the functions > documented in err(3) > > LC_MONETARY > localeconv(3), nl_langinfo(3), strfmon() > > LC_NUMERIC > atof(3), localeconv(3), nl_langinfo(3), strfmon(), and > the functions documented in printf(3), scanf(3), > strtod(3), wcstod(3), wprintf(3), wscanf(3). This > category is particularly dangerous because it can cause > bugs in the parsing and formatting of numbers, for > example failures to recognize or properly write decimal > points. > > LC_TIME > getdate(), nl_langinfo(3), strftime(3), strptime(3). > Similarly, this is prone to causing bugs in the parsing > and formatting of date strings. > > LC_CTYPE > On systems other than OpenBSD, this category may affect > the behaviour of additional functions, for example: > btowc(3), isalnum(3), isalpha(3), isblank(3), iscntrl(3), > isdigit(3), isgraph(3), islower(3), isprint(3), > ispunct(3), isspace(3), isupper(3), isxdigit(3), >
Re: Localization of date(1) and XFCE
Hi, Jan Stary wrote on Tue, Jun 22, 2021 at 11:24:15AM +0200: > On Jun 20 18:58:31, ffuen...@texto-plano.xyz wrote: >> I speak Spanish and thus I use a locale called es_CL.UTF-8. XFCE is fine >> with it. However, my date is expressed directly as it comes from date(1). >> This is confirmed by their docs >> https://docs.xfce.org/xfce/xfce4-panel/4.16/clock so how do I make date to >> work with my language. >> >> This is my locale: >> >> LANG=es_CL.UTF-8 >> LC_COLLATE="es_CL.UTF-8" >> LC_CTYPE="es_CL.UTF-8" >> LC_MONETARY="es_CL.UTF-8" >> LC_NUMERIC="es_CL.UTF-8" >> LC_TIME="es_CL.UTF-8" >> LC_MESSAGES="es_CL.UTF-8" >> LC_ALL=es_CL.UTF-8 > man locale > > Programs in the OpenBSD base system ignore the locale except > for the character encoding, and it is not recommended to > use any of these variables except that the following > non-default setting is supported as an option: > > export LC_CTYPE=en_US.UTF-8 > > OpenBSD's date(1) ignores your locale setting. That's the correct answer, and there are no plans to change that in the future. The reason is that we prioritize simplicity and maintainablity of the C library, and consequently correctness and security, over localization of base system facilities. On top of that, even if you do not take the horrible complication of the library code that LC_* support would imply into account, LC_* also poses some security risks from the user perspective, in particular in system administration and maintenance contexts. Predicatbility of output, and consistent parsing of input, is more valuable for low-level work than localization. Perspectives may vary, but my personal opinion is that adding all those LC_* variables to POSIX was a mistake. The C library is not a reasonable place to handle higly specialized and highly complicated topics like localization. They belong into specialized programs like typesettung software, UI libraries and the like, not into a general-purpose operating system. In general, we try to follow POSIX because standardization and portability have significant advantages. But there are limits. If standards requirements are too bad, we may decide to ignore them in some (rare) cases. Hence, on OpenBSD, you can rely on predictable output from strftime(3) and on predictable parsing by strptime(3). All this is mostly documented, for example: STRFTIME(3)Library Functions Manual [...] CAVEATS On systems other than OpenBSD, the LC_TIME locale(1) category can cause erratic output; see CAVEATS in setlocale(3) for details. SETLOCALE(3) Library Functions Manual [...] CAVEATS On systems other than OpenBSD, calling setlocale() or uselocale(3) with a category other than LC_CTYPE can cause erratic behaviour of many library functions. For security reasons, make sure that portable programs only use LC_CTYPE. For example, the following functions may be affected. The list is probably incomplete. For example, additional library functions may be impacted if they directly or indirectly call affected functions, or if they attempt to imitate aspects of their behaviour. Functions that are not standardized may be affected too. LC_COLLATE glob(3), strcoll(3), strxfrm(3), wcscoll(3), wcsxfrm(3), and the functions documented in regexec(3) LC_MESSAGES catgets(3), catopen(3), nl_langinfo(3), perror(3), psignal(3), strerror(3), strsignal(3), and the functions documented in err(3) LC_MONETARY localeconv(3), nl_langinfo(3), strfmon() LC_NUMERIC atof(3), localeconv(3), nl_langinfo(3), strfmon(), and the functions documented in printf(3), scanf(3), strtod(3), wcstod(3), wprintf(3), wscanf(3). This category is particularly dangerous because it can cause bugs in the parsing and formatting of numbers, for example failures to recognize or properly write decimal points. LC_TIME getdate(), nl_langinfo(3), strftime(3), strptime(3). Similarly, this is prone to causing bugs in the parsing and formatting of date strings. LC_CTYPE On systems other than OpenBSD, this category may affect the behaviour of additional functions, for example: btowc(3), isalnum(3), isalpha(3), isblank(3), iscntrl(3), isdigit(3), isgraph(3), islower(3), isprint(3), ispunct(3), isspace(3), isupper(3), isxdigit(3), mbsinit(3), strcasecmp(3), strcoll(3), strxfrm(3), tolower(3), toupper(3), vis(3), wcscoll(3), wcsxfrm(3), wctob(3) Yours, Ingo
Re: mount(8) security and symlink(7)
> And i am going to suggest you show a diff, and go through the process > Ingo just described as i said, i am new to this, and wanted to discuss something in words before providing a C diff that would doubtless be rejected given that i have only just begun to learn C. i would have been happy to try to contribute a diff, but i felt it better to first bring it up on misc seeing as i am new to OpenBSD and C programming, and (a) my idea might be rejected; (b) my programming skills might not be up to scratch and my patch therefore worthless. my own solution was to use another shell program in the unix fashion, but certainly i will try to diff the source, but it will take a while given that it is new to me and no ones first priority. > or alternative you realize you are lazy ... or a novice. > not allowed to tell others what to do, and you can then shut up. ... or make suggestions... > Really making friends. i am not trying to make friends with someone who will insult me for making a suggestion and giving my honest opinion. i am trying to learn programming and improve the system that runs all my machines. and i didnt mean that facetiously. it really was a bug that i would have had not knowledge of were it not for the patch; it really did remind me of the morris worm which i had just learnt about; and it really did make me think i could do something to help with OpenBSD, seeing as i was disgusted when i first came across system(3), and only satisfied when i learnt about execv(3), which was the first system call i used, and only a short while ago. and even though i persist because i am more interested in BSD than theo, you still have some paranoia that i have some agenda against you.
Re: mount(8) security and symlink(7)
Reuben ua Bríġ wrote: > hi ingo, thanks for your reply. > > > I can't talk about the internals of the mount(2) syscall, > > so i pass on that one to people who know better. > > !!! i feel i should emphasize, > i am *not* presently suggesting any change to the mount(2) *system call* > i *am* suggesting a change to the mount(8) *command* And i am going to suggest you show a diff, and go through the process Ingo just described or alternative you realize you are lazy, not allowed to tell others what to do, and you can then shut up. > of the morris-worm, i felt maybe it was within my grasp to help improve > OpenBSD, but obviously theo has other ideas. Really making friends.
Re: mount(8) security and symlink(7)
hi ingo, thanks for your reply. > I can't talk about the internals of the mount(2) syscall, > so i pass on that one to people who know better. !!! i feel i should emphasize, i am *not* presently suggesting any change to the mount(2) *system call* i *am* suggesting a change to the mount(8) *command* i would expect C programmers to know what they are doing, but not some Charlie root who wants to make hotplugd(8) mount(8) an sd(4). i feel i should also emphasize, i am new to this, and did not expect anything out of it. i use OpenBSD, and after learning that OpenSTMP had used sytem(3) rather than execv(3) resulting in a bug reminiscent of the morris-worm, i felt maybe it was within my grasp to help improve OpenBSD, but obviously theo has other ideas. keep up the good work, reuben.
Re: mount(8) security and symlink(7)
Hi, Reuben ua Brig wrote: > when OpenBSD is happy to change even man.conf We change things when all of the following hold: 1. There is a significant problem to be solved, or a significant profit to be gained. Regarding man.conf: the old format was over-engineered, wordy, hard to use, too closely tied to implementation details of the old man(1) and apropos(1) programs, and ill-suited to work with the then-new mandoc.db(5). 2. Someone does the complete design and the complete implementation. In the case of man.conf(5), that was me. 3. There is broad agreement among developers, *after* step 2 is complete, that downsides are acceptable, that benefits suffienctly outweigh the downsides, and that the design and implementation meet our quality standards. In the case of man.conf(5), most users weren't affected at all. A few had to replace one big configuration file with a small one that would be easier to maintain going forward. A tiny number of people might no longer have been able to use idiosyncratic configurations that didn't work all that well even before the change and certainly weren't advisable in the first place; but frankly, i don't recall a single report to that effect. I can't talk about the internals of the mount(2) syscall, so i pass on that one to people who know better. That one thing is changed in a significant way does not imply that something else is easy to improve as well. Yours, Ingo
Re: mount(8) security and symlink(7)
> If your proposal is to error when the check fails, it will break > hundreds of user machines. > > If your proposal is to emit a warning, it will emit multiple > additional lines of output at boot for correct existing > configurations. > > But you didn't implement a prototype, you didn't test it, yet you > expect to be taken seriously. it works fine on my system, where the mounts are default + source + various external storage. i think most systems this breaks are probably insecure and should use instead use a symlink as i described in my original post. for the few custom setups where some user is trusted not to overwrite a mount point (or where they should be able to), it would not be hard to add a line permit group trusty /usr/trusty to a mount.conf file. > You really don't seem to read. is this because i did not reply to some of your point? i felt doing so would have strayed beyond usefulness. > Your comment about man.conf suggests we changed something which you > hate and you want to wield it against us. my point is that my impression of OpenBSD and your own policy has been that it is acceptable to break a configuration to better security, and that new users are not expected to become unix security gurus overnight. > Your approach is hostile. i am not the one insulting your ability with language.
Re: mount(8) security and symlink(7)
Reuben ua Bríġ wrote: > > I wonder why noone implimented such checks like that in the last 30 > > years. Might be because it breaks more than it fixes. > > i cant tell if you are being sarcastic or what it could possibly break > or why that would matter when OpenBSD is happy to change even man.conf I am not being sarcastic. If your proposal is to error when the check fails, it will break hundreds of user machines. If your proposal is to emit a warning, it will emit multiple additional lines of output at boot for correct existing configurations. But you didn't implement a prototype, you didn't test it, yet you expect to be taken seriously. I cannot tell if that is laziness or if you are used to bossing people around with hand-wavy ideas and expecting them to follow your wishes. Get used to dissapointment. You really don't seem to read. Your comment about man.conf suggests we changed something which you hate and you want to wield it against us. Your approach is hostile. I don't have time for you.
Re: mount(8) security and symlink(7)
> I wonder why noone implimented such checks like that in the last 30 > years. Might be because it breaks more than it fixes. i cant tell if you are being sarcastic or what it could possibly break or why that would matter when OpenBSD is happy to change even man.conf
Re: mount(8) security and symlink(7)
Reuben ua Bríġ wrote: > > Probably because testing for the situation would be an unreliable > > race. BTW, you explain the ssh behaviour incorrectly. It does not > > warn. It fails, and refuses to continue. Failure is not permitted > > for the mount system call in this circumstance, and the entire path > > upwards cannot be verified atomically. A racy warning also requires > > warning to stderr. There are lots of complex considereations to your > > handwavy propose. > > i would think the mount(8) command could examine each node of the path > before the actual mount point and check that they are owned root:wheel > and o-w. only root and wheel could run the race then. I wonder why noone implimented such checks like that in the last 30 years. Might be because it breaks more than it fixes.
Re: mount(8) security and symlink(7)
> Probably because testing for the situation would be an unreliable > race. BTW, you explain the ssh behaviour incorrectly. It does not > warn. It fails, and refuses to continue. Failure is not permitted > for the mount system call in this circumstance, and the entire path > upwards cannot be verified atomically. A racy warning also requires > warning to stderr. There are lots of complex considereations to your > handwavy propose. i would think the mount(8) command could examine each node of the path before the actual mount point and check that they are owned root:wheel and o-w. only root and wheel could run the race then. as for the mount(2) system call, no one makes a boo boo in C, right?
Re: mount(8) security and symlink(7)
Reuben ua Bríġ wrote: > mount(8) will follow a symlink(7), so obviously it is *very* stupid to > mount under a directory a user other than root has write permission for, > as they could, for example > > rm -rf path > ln -s /etc path > > ? so why doesnt the man page for mount(8) mention anything. Over decades, manual page authors have put in their best effort documenting the most important details. As a result, sometimes manual pages won't document the 1 specific detail you want to complain is missing. No manual page can document absolutely everything. They would turn into books, and as the total volume of text increases which needs to be handled by the same number of people, maintainance would become more difficult and overall quality would suffer. This symbolic link concern does not just apply to mounting, it is a fundamental aspect of unix resolution. There is also risk of over-documenting. An explanation or warning would probably take 2 sentences. Using space to focus on this problem might detract readers from absorbing other documentation details. The risk you describe is simply the outcome of a part of unix, and it applies to everything that uses a path. So why document it just in one manual page? I notice you didn't propose a clean change to the manual page. Maybe you recognize the effort involved to add text to the manual page in a clean way. > ? why doesnt mount(8) warn when a mount is unsafe, > like ssh(1) does with ~/.ssh Probably because testing for the situation would be an unreliable race. BTW, you explain the ssh behaviour incorrectly. It does not warn. It fails, and refuses to continue. Failure is not permitted for the mount system call in this circumstance, and the entire path upwards cannot be verified atomically. A racy warning also requires warning to stderr. There are lots of complex considereations to your handwavy propose.
mount(8) security and symlink(7)
mount(8) will follow a symlink(7), so obviously it is *very* stupid to mount under a directory a user other than root has write permission for, as they could, for example rm -rf path ln -s /etc path ? so why doesnt the man page for mount(8) mention anything. ? why doesnt mount(8) warn when a mount is unsafe, like ssh(1) does with ~/.ssh it can be quite tempting to make hotplugd mount thumb drives under the home directory of whoever is at a workstation... obviously the safe way to do it is use symlink(7) *for* security, and make a link to /mnt under the users home directory, rather than the other way round! cheers, reuben. --- thanks for all the fsck!
Re: Question Regarding The 'poolp' Guide On How To Deploy A Mail Server's Last Portion Regarding Dovecot With 'sieve' Scripts
June 25, 2021 5:08 AM, "Samuel Banya" wrote: > > [...] > > Here is the output of running the following command in > '/usr/local/dovecot/sieve' as the 'root' > user on the box, but received the following message: > #+BEGIN_SRC bash > l# sievec report-ham.sieve > report-ham: line 1: error: require command: unknown Sieve capability > `vnd.dovecot.pipe'. > report-ham: line 1: error: require command: unknown Sieve capability > `imapsieve'. > report-ham: line 15: error: unknown command 'pipe' (only reported once at > first occurrence). > report-ham: error: validation failed. > sievec(root): Fatal: failed to compile sieve script 'report-ham.sieve' > # sievec report-spam.sieve > report-spam: line 1: error: require command: unknown Sieve capability > `vnd.dovecot.pipe'. > report-spam: line 1: error: require command: unknown Sieve capability > `imapsieve'. > report-spam: line 7: error: unknown command 'pipe' (only reported once at > first occurrence). > report-spam: error: validation failed. > sievec(root): Fatal: failed to compile sieve script 'report-spam.sieve' > #+END_SRC > > Is there anything else that can be done? > Are you sure that you installed the dovecot-pigeonhole and didn't miss that step ? > Don't mean to be that guy, but I get the feeling that it might have to be an > OpenBSD issue in terms > of the sievec package, or the Dovecot release. > It is very doubtful. Not only a lot of people are using it and giving feedback about their working setup, but I have also reinstalled a mail server from scratch last week and since I have an issue remembering the dovecot bits, I used the guide as reference. Maybe there's an issue in OpenBSD or the guide and we somehow all dodged it, but I'd assume an error on your side to be more likely at this point :-) > Please let me know what I could do to further troubleshoot the issue. > make sure dovecot-pigeonhole is installed and if that's the case, I'd uninstall both dovecot and dovecot-pigeonhole, move /etc/dovecot to /etc/dovecot.BAK, then go again from scratch in case you messed up something in the process. Gilles
Re: Question Regarding The 'poolp' Guide On How To Deploy A Mail Server's Last Portion Regarding Dovecot With 'sieve' Scripts
On 2021-06-25, gil...@poolp.org wrote: > June 25, 2021 5:08 AM, "Samuel Banya" wrote: > >> >> [...] >> >> Here is the output of running the following command in >> '/usr/local/dovecot/sieve' as the 'root' >> user on the box, but received the following message: >> #+BEGIN_SRC bash >> l# sievec report-ham.sieve >> report-ham: line 1: error: require command: unknown Sieve capability >> `vnd.dovecot.pipe'. >> report-ham: line 1: error: require command: unknown Sieve capability >> `imapsieve'. >> report-ham: line 15: error: unknown command 'pipe' (only reported once at >> first occurrence). >> report-ham: error: validation failed. >> sievec(root): Fatal: failed to compile sieve script 'report-ham.sieve' >> # sievec report-spam.sieve >> report-spam: line 1: error: require command: unknown Sieve capability >> `vnd.dovecot.pipe'. >> report-spam: line 1: error: require command: unknown Sieve capability >> `imapsieve'. >> report-spam: line 7: error: unknown command 'pipe' (only reported once at >> first occurrence). >> report-spam: error: validation failed. >> sievec(root): Fatal: failed to compile sieve script 'report-spam.sieve' >> #+END_SRC >> >> Is there anything else that can be done? >> > > Are you sure that you installed the dovecot-pigeonhole and didn't miss that > step ? > > >> Don't mean to be that guy, but I get the feeling that it might have to be an >> OpenBSD issue in terms >> of the sievec package, or the Dovecot release. >> > > It is very doubtful. > > Not only a lot of people are using it and giving feedback about their working > setup, > but I have also reinstalled a mail server from scratch last week and since I > have an > issue remembering the dovecot bits, I used the guide as reference. > > Maybe there's an issue in OpenBSD or the guide and we somehow all dodged it, > but I'd > assume an error on your side to be more likely at this point :-) > > >> Please let me know what I could do to further troubleshoot the issue. >> > > make sure dovecot-pigeonhole is installed and if that's the case, I'd > uninstall both > dovecot and dovecot-pigeonhole, move /etc/dovecot to /etc/dovecot.BAK, then > go again > from scratch in case you messed up something in the process. > > Gilles > > I'm only using Dovecot with Postfix not OpenSMTPd, but don't think there will be any difference to the sieve side of things and that works fine here. I have Dovecot on multiple OpenBSD setups, including with sieve/imapsieve, SSH-based dsync (replicator), FTS (I use solr; dovecot-fts-xapian works too). The only problem I'm aware of with Dovecot and OpenBSD is with TLS-based dsync which doesn't cope with libressl very well (the main part of Dovecot has no problem it's just with replicator).
Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?
On 2021-06-25, Theo Buehler wrote: > If we want to go the cherry-picking route, here's a diff that fixes the > test.csv.gz test case provided in the linked issue. No objection to this (it won't make a future sync much harder, there are already many changes in openbsd-zlib compared to the more common version), but there are plenty of ports that do specifically ask for a newer version that we have hacked away the version check, there is probably some reason they have decided to require the version they do (though many are so old probably nobody remembers by now). >From the ports side a larger update would be welcome. FWIW my earlier update is here: https://marc.info/?l=openbsd-tech=132810606729160=2 (it wasn't just "dump the new code in", I did merge OpenBSD changes). Hacking around missing functions has introduced some problems in ports development. And different codepaths taken mean we hit bugs in upstream software that are not seen by others. mail/notmuch is an example where we found problems (https://marc.info/?l=openbsd-ports=158654770825909=2) and fixed/worked around them because it has a good regression testsuite; that's not all that common in other ports so I'll be surprised if there are no other issues latent in the tree (I guess it took some time before the problem with R prpmpting this discussion showed up). But ports can't answer Mark's question about z_off64_t. > the copy in gnu/usr.bin/cvs is even older... Fortunately that one's unused.
