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: 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!
