From yury at shurup.com Sun Mar 5 15:26:54 2017 From: yury at shurup.com (Yury V. Zaytsev) Date: Sun, 05 Mar 2017 16:26:54 +0100 Subject: Midnight Commander 4.8.19 released Message-ID: <1488727614.9748.38.camel@newpride> Hi, I'm glad to announce the immediate availability of mc-4.8.19! This is a maintenance release which includes many bugfixes and several new exciting features, the most notable of which are support for True Color capable terminals (and first skins!) contributed by Egmont Koblinger and support for timestamps with nanosecond precision on Linux contributed by Andrey Gursky. For the detailed list of changes since the last release, please refer to the release notes. Download page: http://ftp.midnight-commander.org/?C=N;O=D Release notes: http://www.midnight-commander.org/wiki/NEWS-4.8.19 Traditionally, big thanks goes to our hero committer Andrew Borodin, as well as our regular contributors Mooffie, Andreas Mohr and others, including our translators. This time I have the particular pleasure to welcome Mooffie of the friendly mc^2 fork's fame as our new committer, and note how he has already delivered many valuable additions to mc for this release, including an actual test suite for the extfs helpers! As always, we hope to accept more patches for the next version, with many waiting for reviews and tests, of which we sadly have way too few, but our resources are constrained as ever, so bear with us. Having that said, we in full choir hail thy approach, O Spring! -- Sincerely yours, Yury V. Zaytsev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From l.wandrebeck at quelquesmots.fr Sun Mar 5 17:33:12 2017 From: l.wandrebeck at quelquesmots.fr (Laurent Wandrebeck) Date: Sun, 05 Mar 2017 18:33:12 +0100 Subject: Midnight Commander 4.8.19 released In-Reply-To: <1488727614.9748.38.camel@newpride> References: <1488727614.9748.38.camel@newpride> Message-ID: <1488735192.5359.2.camel@quelquesmots.fr> Le dimanche 05 mars 2017 ? 16:26 +0100, Yury V. Zaytsev a ?crit?: > Hi, > > I'm glad to announce the immediate availability of mc-4.8.19! > > This is a maintenance release which includes many bugfixes and > several > new exciting features, the most notable of which are support for True > Color capable terminals (and first skins!) contributed by Egmont > Koblinger and support for timestamps with nanosecond precision on > Linux > contributed by Andrey Gursky. > > For the detailed list of changes since the last release, please refer > to > the release notes. > > Download page: http://ftp.midnight-commander.org/?C=N;O=D > Release notes: http://www.midnight-commander.org/wiki/NEWS-4.8.19 > > Traditionally, big thanks goes to our hero committer Andrew Borodin, > as > well as our regular contributors Mooffie, Andreas Mohr and others, > including our translators. > > This time I have the particular pleasure to welcome Mooffie of the > friendly mc^2 fork's fame as our new committer, and note how he has > already delivered many valuable additions to mc for this release, > including an actual test suite for the extfs helpers! > > As always, we hope to accept more patches for the next version, with > many waiting for reviews and tests, of which we sadly have way too > few, > but our resources are constrained as ever, so bear with us. > > Having that said, we in full choir hail thy approach, O Spring! > > _______________________________________________ > mc mailing list > https://mail.gnome.org/mailman/listinfo/mc Hi Yuri, all. First, thanks to all of you for that release. I?ve updated ? my ? packages on OpenSuSe Build Service to 4.8.19? for the following distros: CentOS and Scientific Linux 6 i586 and x86_64. CentOS and Scientific Linux 7 x86_64. Fedora 24, 25, i586 and x86_64. I?ve used official tar.xz package, and mc was built with the? following options: ????????--with-screen=slang \ ????????--enable-charset \ ????????--with-x \ ????????--with-gpm-mouse \ ????????--disable-rpath \ ????????--enable-vfs-smb \ ????????--enable-vfs-sftp \ ????????--enable-aspell You can get packages here:? https://build.opensuse.org/package/repositories/home:laurentwandrebeck: mc/mc Thanks, -- Laurent Wandrebeck From yury at shurup.com Mon Mar 6 06:24:38 2017 From: yury at shurup.com (Yury V. Zaytsev) Date: Mon, 6 Mar 2017 07:24:38 +0100 (CET) Subject: Midnight Commander 4.8.19 released In-Reply-To: <20170305232432.1dcb8f06@sf> References: <1488727614.9748.38.camel@newpride> <20170305232432.1dcb8f06@sf> Message-ID: Hi, On Sun, 5 Mar 2017, Sergei Trofimovich wrote: > Yay! Looks like a set of vfs shell helpers were added in here. If I remember correctly, no new helpers, but many existing helpers turned out to be broken and were fixed after the test suite was introduced. > When running 'make check' I have single extfs test failure: > # FAIL: 1 > See tests/src/vfs/extfs/helpers-list/test-suite.log Thanks, we'll have a look. > The log file is missing actual diff. I suggest adding diff output inline > to ease bug reporting. Might be a good idea, I thought the diff was generated in the temporary directory, but apparently, this is not the case. > And a few others. These tests look fragile. That's very curious, because the tests shouldn't be actually using the tools themselves, but they should rather be only checking whether the extfs scripts are still able to parse pre-recorded output of the tools. Therefore, I would hope that it's not version drift of the tools, but rather coreutils / awk / ... whatever the scripts depend upon to parse pre-recorded output, and as such you have identified a valid problem with parsing not being robust enough / working differently with newer coreutils / awk / etc. Or else, in your case, real output is used instead of mocked stuff, which would be truly bizarre, but would also point to a valid problem with the test suite. One thing is clear though, something's gone wrong here, could you please be so kind to create a ticket? Thanks! -- Sincerely yours, Yury V. Zaytsev From slyfox at inbox.ru Mon Mar 6 09:11:50 2017 From: slyfox at inbox.ru (Sergei Trofimovich) Date: Mon, 6 Mar 2017 09:11:50 +0000 Subject: Midnight Commander 4.8.19 released In-Reply-To: References: <1488727614.9748.38.camel@newpride> <20170305232432.1dcb8f06@sf> Message-ID: <20170306091150.546653fe@sf> On Mon, 6 Mar 2017 07:24:38 +0100 (CET) "Yury V. Zaytsev" wrote: > One thing is clear though, something's gone wrong here, could you please > be so kind to create a ticket? Thanks! Sure. Filed http://midnight-commander.org/ticket/3781 -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: ???????????????? ?????????????? OpenPGP URL: From slyfox at inbox.ru Sun Mar 5 23:30:43 2017 From: slyfox at inbox.ru (Sergei Trofimovich) Date: Sun, 5 Mar 2017 23:30:43 +0000 Subject: Midnight Commander 4.8.19 released In-Reply-To: <1488727614.9748.38.camel@newpride> References: <1488727614.9748.38.camel@newpride> Message-ID: <20170305232432.1dcb8f06@sf> On Sun, 05 Mar 2017 16:26:54 +0100 "Yury V. Zaytsev" wrote: > Hi, > > I'm glad to announce the immediate availability of mc-4.8.19! [ Using correct source address this time ] Yay! Looks like a set of vfs shell helpers were added in here. When running 'make check' I have single extfs test failure: # FAIL: 1 See tests/src/vfs/extfs/helpers-list/test-suite.log [ attached ] The log file is missing actual diff. I suggest adding diff output inline to ease bug reporting. Most of test don't like tool versions (or flavours?) I have: Diffing manually: > /home/slyfox/dev/git/mc/tests/src/vfs/extfs/helpers-list/data/rpm.custom.output /tmp/rpm.actual-parsed-output.A09GDxro differ: char 42, line 1 1. rpm: $ diff -U0 /home/slyfox/dev/git/mc/tests/src/vfs/extfs/helpers-list/data/rpm.custom.output /tmp/rpm.actual-parsed-output.A09GDxro --- /home/slyfox/dev/git/mc/tests/src/vfs/extfs/helpers-list/data/rpm.custom.output 2017-01-22 16:42:40.730438199 +0000 +++ /tmp/rpm.actual-parsed-output.A09GDxro 2017-03-05 23:14:49.741128300 +0000 @@ -1 +1 @@ --r--r--r-- 1 0 0 539 2017-01-05 00:00:00 HEADER +-r--r--r-- 1 0 0 597 2017-01-05 00:00:00 HEADER @@ -15,0 +16 @@ +-r--r--r-- 1 0 0 0 2017-01-05 00:00:00 INFO/SUMMARY @@ -30,0 +32,7 @@ +-r--r--r-- 1 0 0 0 2017-01-05 00:00:00 INFO/PACKAGER +-r--r--r-- 1 0 0 0 2017-01-05 00:00:00 INFO/URL +-r--r--r-- 1 0 0 0 2017-01-05 00:00:00 INFO/EPOCH +-r--r--r-- 1 0 0 0 2017-01-05 00:00:00 INFO/LICENSE +-r--r--r-- 1 0 0 0 2017-01-05 00:00:00 INFO/REQUIRES +-r--r--r-- 1 0 0 0 2017-01-05 00:00:00 INFO/OBSOLETES +-r--r--r-- 1 0 0 0 2017-01-05 00:00:00 INFO/PROVIDES I don't have 'rpm' installed but I have 'rpm2targz'. But not sure from the output which tool was actually used. > /home/slyfox/dev/git/mc/tests/src/vfs/extfs/helpers-list/data/u7z.complex.output /tmp/u7z.actual-parsed-output.DTg79ID0 differ: char 38, line 1 2. u7z $ diff -U0 /home/slyfox/dev/git/mc/tests/src/vfs/extfs/helpers-list/data/u7z.complex.output /tmp/u7z.actual-parsed-output.DTg79ID0 --- /home/slyfox/dev/git/mc/tests/src/vfs/extfs/helpers-list/data/u7z.complex.output 2017-01-22 16:42:40.731438194 +0000 +++ /tmp/u7z.actual-parsed-output.DTg79ID0 2017-03-05 23:14:49.822129852 +0000 @@ -1,7 +1,6 @@ --rw-r--r-- 1 <> <> 469920 2011-11-03 02:33:04 cpuidsdk64.dll --rw-r--r-- 1 <> <> 445814 2011-11-03 02:33:04 cpuidsdk.dll --rw-r--r-- 1 <> <> 1178084 2011-11-03 02:33:04 Geekbench22.exe --rw-r--r-- 1 <> <> 101652 2011-11-03 02:33:04 geekbench.exe --rw-r--r-- 1 <> <> 737580 2011-11-03 02:33:04 geekbench.plar --rw-r--r-- 1 <> <> 1058731 2011-11-03 02:33:06 geekbench_x86_32.exe --rw-r--r-- 1 <> <> 1192155 2011-11-03 02:33:06 geekbench_x86_64.exe +-rw-r--r-- 1 <> <> 6144 2007-07-07 07:07:07 $PLUGINSDIR/AdvSplash.dll +-rw-r--r-- 1 <> <> 8005 2007-07-07 07:07:07 $PLUGINSDIR/InstallOptions.dll +-rw-r--r-- 1 <> <> 3328 2007-07-07 07:07:07 $PLUGINSDIR/StartMenu.dll +-rw-r--r-- 1 <> <> 134 2007-11-15 01:12:38 $PLUGINSDIR/ioSpecial.ini +-rw-r--r-- 1 <> <> 1886 2003-09-24 00:34:00 $PLUGINSDIR/modern-wizard.bmp +-rw-r--r-- 1 <> <> 28016 2006-08-11 23:49:28 $PLUGINSDIR/splash.bmp @@ -12 +10,0 @@ --rw-r--r-- 1 <> <> 9854 2011-11-03 02:23:16 $_OUTDIR/html/ui/heading-bg.gif @@ -13,0 +12 @@ +-rw-r--r-- 1 <> <> 9854 2011-11-03 02:23:16 $_OUTDIR/html/ui/heading-bg.gif @@ -16 +14,0 @@ --rw-r--r-- 1 <> <> 1425 2011-11-03 02:23:16 $_OUTDIR/html/ui/nav-arrows-bg.gif @@ -18 +16 @@ --rw-r--r-- 1 <> <> 2885 2011-11-03 02:23:16 $_OUTDIR/html/ui/table-wrapper-bg-repeat.gif +-rw-r--r-- 1 <> <> 1425 2011-11-03 02:23:16 $_OUTDIR/html/ui/nav-arrows-bg.gif @@ -19,0 +18 @@ +-rw-r--r-- 1 <> <> 2885 2011-11-03 02:23:16 $_OUTDIR/html/ui/table-wrapper-bg-repeat.gif @@ -21,6 +20,7 @@ --rw-r--r-- 1 <> <> 6144 2007-07-07 07:07:07 $PLUGINSDIR/AdvSplash.dll --rw-r--r-- 1 <> <> 8005 2007-07-07 07:07:07 $PLUGINSDIR/InstallOptions.dll --rw-r--r-- 1 <> <> 134 2007-11-15 01:12:38 $PLUGINSDIR/ioSpecial.ini --rw-r--r-- 1 <> <> 1886 2003-09-24 00:34:00 $PLUGINSDIR/modern-wizard.bmp --rw-r--r-- 1 <> <> 28016 2006-08-11 23:49:28 $PLUGINSDIR/splash.bmp --rw-r--r-- 1 <> <> 3328 2007-07-07 07:07:07 $PLUGINSDIR/StartMenu.dll +-rw-r--r-- 1 <> <> 1178084 2011-11-03 02:33:04 Geekbench22.exe +-rw-r--r-- 1 <> <> 445814 2011-11-03 02:33:04 cpuidsdk.dll +-rw-r--r-- 1 <> <> 469920 2011-11-03 02:33:04 cpuidsdk64.dll +-rw-r--r-- 1 <> <> 101652 2011-11-03 02:33:04 geekbench.exe +-rw-r--r-- 1 <> <> 737580 2011-11-03 02:33:04 geekbench.plar +-rw-r--r-- 1 <> <> 1058731 2011-11-03 02:33:06 geekbench_x86_32.exe +-rw-r--r-- 1 <> <> 1192155 2011-11-03 02:33:06 geekbench_x86_64.exe No idea what's happened here either. I guess slight p7zip version drift. '7z' reports this version here: 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 And a few others. These tests look fragile. -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: test-suite.log Type: text/x-log Size: 6532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: ???????????????? ?????????????? OpenPGP URL: From key.offecka at gmail.com Fri Mar 10 00:06:00 2017 From: key.offecka at gmail.com (Key Offecka) Date: Thu, 9 Mar 2017 19:06:00 -0500 Subject: A requirement for the current user to own ttys Message-ID: Hi, I am looking at the main (int argc, char **argv) function in src/consaver/cons.saver.c There are calls like st.st_uid != uid fstat (console_fd, &st) >= 0 && st.st_uid == uid fstat (console_fd, &st) < 0 || st.st_uid != uid The last one is especially strange taking into account that it appears twice if (seteuid (euid) < 0 || lseek (vcsa_fd, 0, 0) != 0 || fstat (console_fd, &st) < 0 || st.st_uid != uid || read (vcsa_fd, buffer, buffer_size) != buffer_size || fstat (console_fd, &st) < 0 || st.st_uid != uid) This all is taken from the commit e9fd11bfcd1dab97e3ba423bcfb8b6ca1088b11c which is the latest at this moment It looks to me MC tries inventing its own permission scheme rather than relying on the system set up. Consider there is a user in the system who is allowed to read/write and to do whatever they want with vcs, tty and with whatever files else you may only wish. root is one obvious candidate but nothing restricts us to set up another user taking advantaged of all those system security facilities. There is a traditional UNIX permission scheme, SeLinux may be involved if needed. And now comes MC, and introduces a hardcoded/unconfigurable/solid as a stone requirement for the current user to be the owner of the files. Why so? I believe there is case and that code is called to cover it. But unfortunately I do not see the reason. And this is my question, I would appreciate if anybody could explain what security issue was addressed here? In my particular case this code introduces an inconvenience, so I just removed it and feel total happy without it. But still am a little bit concerned about possible consequences which I do now understand at the moment. My case I mentioned above is as follows: Log into, say, tty3 as a normal user, say `echo`. The tty3 ownership changes, and the `echo` user becomes the owner of tty3 which sounds reasonable. Now sudo as another user who has all access permissions to tty and vcs, In my case this is root. Press Control+O, MC screws up the background shell, the root user sees the blank screen rather than previously executed commands and MC starts thinking the terminal is dumb asking to press any key after executing commands. And this happens for the root user! MC overwrote the root privileges! Does it sound reasonable to you? Any explanations are welcome. Thank you. -- Konstantin I., -------------- next part -------------- An HTML attachment was scrubbed... URL: From egmont at gmail.com Fri Mar 10 07:30:06 2017 From: egmont at gmail.com (Egmont Koblinger) Date: Fri, 10 Mar 2017 08:30:06 +0100 Subject: A requirement for the current user to own ttys In-Reply-To: References: Message-ID: Hi, cons.saver, as you apparently know this, is the helper binary responsible for restoring the contents of the Linux console when you quit mc or press Ctrl+O. A helper is required since the Linux console does not have an "alternate screen" that graphical terminal emulators have. In order to be able to do this, it needs read/write access to /dev/vcsa*. When you log in on the console, the corresponding /dev/tty* becomes owned by you but /dev/vcsa* don't. I believe the reason behind it is that there is a way to revoke the tty from you, but there is no way to revoke the vcsa access. That is, when you log out, you might keep a background process running which still has access to it via a previously opened file descriptor, and subsequently as someone else logs in, you could spy on the console's contents. As such, since /dev/vcsa* is not owned by the desired user, cons.saver needs to be setgid tty (or setuid root). Setuid/setgid apps must have all these kinds of precautions that you're asking about, they need to duplicate the permission checks because they are not being run as the actual real user. It's crucial that someone not actually sitting in front of the tty cannot trick cons.saver into tampering with the tty's contents. Hope this explains the situation. I'm not sure why something is checked twice, but it can easily be in order to avoid a race condition (or could easily be a harmless bug as well). egmont On Fri, Mar 10, 2017 at 1:06 AM, Key Offecka wrote: > Hi, > > I am looking at the > > main (int argc, char **argv) > > function in > > src/consaver/cons.saver.c > > There are calls like > > st.st_uid != uid > > fstat (console_fd, &st) >= 0 && st.st_uid == uid > > fstat (console_fd, &st) < 0 || st.st_uid != uid > > The last one is especially strange taking into account that it appears > twice > > if (seteuid (euid) < 0 > || lseek (vcsa_fd, 0, 0) != 0 > || fstat (console_fd, &st) < 0 || st.st_uid != uid > || read (vcsa_fd, buffer, buffer_size) != buffer_size > || fstat (console_fd, &st) < 0 || st.st_uid != uid) > > This all is taken from the commit e9fd11bfcd1dab97e3ba423bcfb8b6ca1088b11c > which is the latest at this moment > > It looks to me MC tries inventing its own permission scheme rather than > relying on the system set up. > Consider there is a user in the system who is allowed to read/write and to > do whatever they want with vcs, tty and with whatever files else you may > only wish. root is one obvious candidate but nothing restricts us to set up > another user taking advantaged of all those system security facilities. > There is a traditional UNIX permission scheme, SeLinux may be involved if > needed. And now comes MC, and introduces a hardcoded/unconfigurable/solid > as a stone requirement for the current user to be the owner of the files. > Why so? > > I believe there is case and that code is called to cover it. But > unfortunately I do not see the reason. And this is my question, I would > appreciate if anybody could explain what security issue was addressed here? > In my particular case this code introduces an inconvenience, so I just > removed it and feel total happy without it. But still am a little bit > concerned about possible consequences which I do now understand at the > moment. > > My case I mentioned above is as follows: > > Log into, say, tty3 as a normal user, say `echo`. The tty3 ownership > changes, and the `echo` user becomes the owner of tty3 which sounds > reasonable. > Now sudo as another user who has all access permissions to tty and vcs, In > my case this is root. > Press Control+O, MC screws up the background shell, the root user sees the > blank screen rather than previously executed commands and MC starts > thinking the terminal is dumb asking to press any key after executing > commands. And this happens for the root user! MC overwrote the root > privileges! Does it sound reasonable to you? > > Any explanations are welcome. > Thank you. > > -- > Konstantin I., > > > _______________________________________________ > mc-devel mailing list > https://mail.gnome.org/mailman/listinfo/mc-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From key.offecka at gmail.com Sat Mar 11 01:33:03 2017 From: key.offecka at gmail.com (Key Offecka) Date: Fri, 10 Mar 2017 20:33:03 -0500 Subject: A requirement for the current user to own ttys In-Reply-To: References: Message-ID: Thank you, egmont, for your time answering my question. All you say about vcs* sounds reasonable, unfortunately according to the code, the tty owner is the problem. fstat (console_fd, &st) < 0 || st.st_uid != uid As far as I understand the c code here, you compare the user id with the id of the tty owner. This happens in the very beginning of the main function, and then in case CONSOLE_SAVE if (seteuid (euid) < 0 || lseek (vcsa_fd, 0, 0) != 0 || fstat (console_fd, &st) < 0 || st.st_uid != uid || read (vcsa_fd, buffer, buffer_size) != buffer_size || fstat (console_fd, &st) < 0 || st.st_uid != uid) and then in case CONSOLE_RESTORE if (seteuid (euid) >= 0 && lseek (vcsa_fd, 0, 0) == 0 && fstat (console_fd, &st) >= 0 && st.st_uid == uid) Yes, you set the effective user id (in case when cons.server has that sticky bit and is owned by vcsa, it is the vcsa user). You need it to be able to lseek (vcsa_fd, 0, 0) and read (vcsa_fd, buffer, buffer_size) But then you compare the owner id of the tty with the real user id (in my example it is the root user), the comparison fails and the root user sees the blank screen in one case, and has to press the `anyKey` in the other as described earlier. Disregarding of what was the intention, disregarding of what you were trying to achieve and what security hole to close, do you think, that sort of comparison is valid here? Thank you. -- Konstantin On 10 March 2017 at 02:30, Egmont Koblinger wrote: > Hi, > > cons.saver, as you apparently know this, is the helper binary responsible > for restoring the contents of the Linux console when you quit mc or press > Ctrl+O. A helper is required since the Linux console does not have an > "alternate screen" that graphical terminal emulators have. > > In order to be able to do this, it needs read/write access to /dev/vcsa*. > > When you log in on the console, the corresponding /dev/tty* becomes owned > by you but /dev/vcsa* don't. I believe the reason behind it is that there > is a way to revoke the tty from you, but there is no way to revoke the vcsa > access. That is, when you log out, you might keep a background process > running which still has access to it via a previously opened file > descriptor, and subsequently as someone else logs in, you could spy on the > console's contents. > > As such, since /dev/vcsa* is not owned by the desired user, cons.saver > needs to be setgid tty (or setuid root). > > Setuid/setgid apps must have all these kinds of precautions that you're > asking about, they need to duplicate the permission checks because they are > not being run as the actual real user. It's crucial that someone not > actually sitting in front of the tty cannot trick cons.saver into tampering > with the tty's contents. > > Hope this explains the situation. > > I'm not sure why something is checked twice, but it can easily be in order > to avoid a race condition (or could easily be a harmless bug as well). > > egmont > > > On Fri, Mar 10, 2017 at 1:06 AM, Key Offecka > wrote: > >> Hi, >> >> I am looking at the >> >> main (int argc, char **argv) >> >> function in >> >> src/consaver/cons.saver.c >> >> There are calls like >> >> st.st_uid != uid >> >> fstat (console_fd, &st) >= 0 && st.st_uid == uid >> >> fstat (console_fd, &st) < 0 || st.st_uid != uid >> >> The last one is especially strange taking into account that it appears >> twice >> >> if (seteuid (euid) < 0 >> || lseek (vcsa_fd, 0, 0) != 0 >> || fstat (console_fd, &st) < 0 || st.st_uid != uid >> || read (vcsa_fd, buffer, buffer_size) != buffer_size >> || fstat (console_fd, &st) < 0 || st.st_uid != uid) >> >> This all is taken from the commit e9fd11bfcd1dab97e3ba423bcfb8b6ca1088b11c >> which is the latest at this moment >> >> It looks to me MC tries inventing its own permission scheme rather than >> relying on the system set up. >> Consider there is a user in the system who is allowed to read/write and >> to do whatever they want with vcs, tty and with whatever files else you may >> only wish. root is one obvious candidate but nothing restricts us to set up >> another user taking advantaged of all those system security facilities. >> There is a traditional UNIX permission scheme, SeLinux may be involved if >> needed. And now comes MC, and introduces a hardcoded/unconfigurable/solid >> as a stone requirement for the current user to be the owner of the files. >> Why so? >> >> I believe there is case and that code is called to cover it. But >> unfortunately I do not see the reason. And this is my question, I would >> appreciate if anybody could explain what security issue was addressed here? >> In my particular case this code introduces an inconvenience, so I just >> removed it and feel total happy without it. But still am a little bit >> concerned about possible consequences which I do now understand at the >> moment. >> >> My case I mentioned above is as follows: >> >> Log into, say, tty3 as a normal user, say `echo`. The tty3 ownership >> changes, and the `echo` user becomes the owner of tty3 which sounds >> reasonable. >> Now sudo as another user who has all access permissions to tty and vcs, >> In my case this is root. >> Press Control+O, MC screws up the background shell, the root user sees >> the blank screen rather than previously executed commands and MC starts >> thinking the terminal is dumb asking to press any key after executing >> commands. And this happens for the root user! MC overwrote the root >> privileges! Does it sound reasonable to you? >> >> Any explanations are welcome. >> Thank you. >> >> -- >> Konstantin I., >> >> >> _______________________________________________ >> mc-devel mailing list >> https://mail.gnome.org/mailman/listinfo/mc-devel >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egmont at gmail.com Sat Mar 11 09:37:26 2017 From: egmont at gmail.com (Egmont Koblinger) Date: Sat, 11 Mar 2017 10:37:26 +0100 Subject: A requirement for the current user to own ttys In-Reply-To: References: Message-ID: Hi, > All you say about vcs* sounds reasonable, unfortunately according to the code, the tty owner is the problem. What do you mean the tty owner is the _problem_? What kind of problem? I believe it's not the _problem_, it's the piece of information we rely on to figure out if cons.saver is being run as a legitime user. > Disregarding of what was the intention, disregarding of what you were trying to achieve and what security hole to close, do you think, that sort of comparison is valid here? I'm not aware of the details of the code and don't have time to dig into it, sorry. As far as I understand, your problem is: You expect that if the real user is root, cons.saver should dutifully perform its role rather than bail out due to some ownership mismatch. Am I right? If so, I believe it's a fair request, although possible security implications should be double checked. Could you please file a new bug for this? Thanks, egmont -------------- next part -------------- An HTML attachment was scrubbed... URL: From key.offecka at gmail.com Sat Mar 11 15:24:42 2017 From: key.offecka at gmail.com (Key Offecka) Date: Sat, 11 Mar 2017 10:24:42 -0500 Subject: A requirement for the current user to own ttys In-Reply-To: References: Message-ID: Hi Egmont, > What do you mean the tty owner is the _problem_? What kind of problem? Please excuse me, I wasn't quite correct there. Let's forget about permissions and TTYs. Let's look at the issue from the user point of view. Please consider this case: There is a user, say `echo` and there is another user, say `ghost`. It can also be `root` but that is not necessary. The requirement here is that the second user (`ghost` in this example) is authorised to act on behalf of `echo`. User `echo` logs on a tty, say tty3. In terms of permissions (OK, it's difficult to forget about them), ghost is a part of the tty group echo:/etc/init.d$ ls -la /dev/tty3 crw-rw---- 1 echo tty 4, 3 mar 11 09:40 /dev/tty3 echo:/etc/init.d$ groups ghost ghost : users root tty wheel echo:/usr/lib/mc$ ls -la cons.saver -rwsr-sr-x 1 vcsa root 10144 mar 11 09:49 cons.saver echo:/usr/lib/mc$ ls -la /dev/vcs{,{,a}3} crw------- 1 vcsa root 7, 0 mar 11 09:28 /dev/vcs crw------- 1 vcsa root 7, 3 mar 11 09:28 /dev/vcs3 crw------- 1 vcsa root 7, 131 mar 11 09:28 /dev/vcsa3 The logged in user `echo` does sudo like so sudo -u ghost mc Now we execute a command in mc, mc runs it but before returning back it shows that ugly message about any key. If we press something, we return to the normal mc panels, but if we want to see the printed results of the previously executed command, we see the blank screen. Question: does mc work in this case as it was designed? The behaviour I would expect: in the example above mc shouldn't stop after executing commands and should show previous command output. The same issue is valid for root, root is just more obvious example of the misbehaviour. And the reason of the misbehaviour in my opinion is that there is a requirement for the tty to be owned by `ghost` in this example. And as I mentioned several times before, this comes from this sort of comparison fstat (console_fd, &st) < 0 || st.st_uid != uid That piece of information shouldn't be used like so. I think to achieve the goals you mentioned above (to not allow others to see what they shouldn't see) another solution should be found. Do you agree? -- Konstantin On 11 March 2017 at 04:37, Egmont Koblinger wrote: > Hi, > > > All you say about vcs* sounds reasonable, unfortunately according to the > code, the tty owner is the problem. > > What do you mean the tty owner is the _problem_? What kind of problem? > > I believe it's not the _problem_, it's the piece of information we rely on > to figure out if cons.saver is being run as a legitime user. > > > Disregarding of what was the intention, disregarding of what you were > trying to achieve and what security hole to close, do you think, that sort > of comparison is valid here? > > I'm not aware of the details of the code and don't have time to dig into > it, sorry. > > As far as I understand, your problem is: You expect that if the real user > is root, cons.saver should dutifully perform its role rather than bail out > due to some ownership mismatch. Am I right? If so, I believe it's a fair > request, although possible security implications should be double checked. > Could you please file a new bug for this? > > Thanks, > egmont > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egmont at gmail.com Sat Mar 11 17:40:19 2017 From: egmont at gmail.com (Egmont Koblinger) Date: Sat, 11 Mar 2017 18:40:19 +0100 Subject: A requirement for the current user to own ttys In-Reply-To: References: Message-ID: Hi, The requirement here is that the second user (`ghost` in this example) is > authorised to act on behalf of `echo`. > Nope. Via "sudo", the first user is allowed to execute certain commands on behalf of the second, not the other way around. During this, the second user doesn't have any access to the first user's resources (e.g. files under its home). As such, it's utterly irrelevant whether tty3 is owned by 'echo' (the first user) or not. It's not owned by 'ghost' (the second user), so no access. If you wish to grant access to tty3 for 'ghost', this should be done by sudo or the pam framework or whatever, definitely not mc. > echo:/etc/init.d$ groups ghost > ghost : users root tty wheel > Seems your 'ghost' is a pretty power user. E.g. he can write to the tty devices, or even hijack the data that's being typed there. Definitely not something a regular user should have. Plus the root and wheel groups. As such, you might just as well put the vcsa devices in a group and chmod 660 and hence allow the ghost user to directly access them. > Question: does mc work in this case as it was designed? > It's a compromise due to the lack of alternate screen support. I'd say mc was designed to paint on the alternate screen, but due to lack thereof it needed to find a workaround. behaviour I would expect: in the example above mc shouldn't stop after > executing commands and should show previous command output. > mc is being executed as user 'ghost'. He has no direct access to the vcsa3 device, and the corresponding tty3 is owned by 'echo'. How do you think mc's cons.saver should figure out that it's safe to grant access? > I think to achieve the goals you mentioned above (to not allow others to > see what they shouldn't see) another solution should be found. Do you agree? > Yup, like implementing alternate screen support in the Linux tty driver, or using a graphical emulator. I can't see how mc could solve this issue. If you can, let us know. cheers, egmont -------------- next part -------------- An HTML attachment was scrubbed... URL: From key.offecka at gmail.com Sat Mar 11 18:50:17 2017 From: key.offecka at gmail.com (Konstantin I.) Date: Sat, 11 Mar 2017 13:50:17 -0500 Subject: A requirement for the current user to own ttys In-Reply-To: References: Message-ID: <15abeb4fe28.27aa.b35410abedec3f2adbea03ab2b9f751b@gmail.com> Hi, > Nope. Via "sudo", the first user is allowed to execute certain commands on > behalf of the second, not the other way around. I didn't say "via sudo" I said: the second user (`ghost` in this example) is authorised?to act on behalf of `echo`. How it's done is irrelevant. You mentioned PAM. Ok. Let it be PAM. Not sure how to set it up, but that's not important. sudo here is just used to switch from echo to ghost. How ghost then gains the access to echo's resources is a different question. > Seems your 'ghost' is a pretty power user. That doesn't matter. That could've been root. root is rejected to see the background as well. It doesn't sound sane to me. >He has no direct access to the vcsa3 device Or she, but anyway they have indirect access via the sticky bit. So it shouldn't be a problem. > and the corresponding tty3 is owned by 'echo'. How do you think mc's > cons.saver should figure out that it's safe to grant access? Please take a look at my ls -la outputs. Not only is tty3 owened by echo but it's owned also by the tty group. And as you saw ghost is a pretty powerful user. The user is a part of the tty group as well. But mc doesn't care. It also doesn't care whether this is root or not. >?implementing alternate screen support in the Linux tty driver, or using a >graphical emulator. I can't see how mc could solve this issue. That would be overkilling. Why not just to follow standard *nix conventions? To respect root privileges at least. May I dare to ask to respect group permissions as well ;-) -- With all my respect, Konstant?n Sent with AquaMail for Android http://www.aqua-mail.com On 11 March 2017 12:41:00 pm Egmont Koblinger wrote: > Hi, > > The requirement here is that the second user (`ghost` in this example) is >> authorised to act on behalf of `echo`. >> > > Nope. Via "sudo", the first user is allowed to execute certain commands on > behalf of the second, not the other way around. During this, the second > user doesn't have any access to the first user's resources (e.g. files > under its home). As such, it's utterly irrelevant whether tty3 is owned by > 'echo' (the first user) or not. It's not owned by 'ghost' (the second > user), so no access. > > If you wish to grant access to tty3 for 'ghost', this should be done by > sudo or the pam framework or whatever, definitely not mc. > > >> echo:/etc/init.d$ groups ghost >> ghost : users root tty wheel >> > > Seems your 'ghost' is a pretty power user. E.g. he can write to the tty > devices, or even hijack the data that's being typed there. Definitely not > something a regular user should have. Plus the root and wheel groups. As > such, you might just as well put the vcsa devices in a group and chmod 660 > and hence allow the ghost user to directly access them. > > >> Question: does mc work in this case as it was designed? >> > > It's a compromise due to the lack of alternate screen support. I'd say mc > was designed to paint on the alternate screen, but due to lack thereof it > needed to find a workaround. > > behaviour I would expect: in the example above mc shouldn't stop after >> executing commands and should show previous command output. >> > > mc is being executed as user 'ghost'. He has no direct access to the vcsa3 > device, and the corresponding tty3 is owned by 'echo'. How do you think > mc's cons.saver should figure out that it's safe to grant access? > > >> I think to achieve the goals you mentioned above (to not allow others to >> see what they shouldn't see) another solution should be found. Do you agree? >> > > Yup, like implementing alternate screen support in the Linux tty driver, or > using a graphical emulator. I can't see how mc could solve this issue. If > you can, let us know. > > > cheers, > egmont -------------- next part -------------- An HTML attachment was scrubbed... URL: From egmont at gmail.com Sat Mar 11 21:24:35 2017 From: egmont at gmail.com (Egmont Koblinger) Date: Sat, 11 Mar 2017 22:24:35 +0100 Subject: A requirement for the current user to own ttys In-Reply-To: <15abeb4fe28.27aa.b35410abedec3f2adbea03ab2b9f751b@gmail.com> References: <15abeb4fe28.27aa.b35410abedec3f2adbea03ab2b9f751b@gmail.com> Message-ID: Hi, On Sat, Mar 11, 2017 at 7:50 PM, Konstantin I. wrote: > Hi, > > > Nope. Via "sudo", the first user is allowed to execute certain commands > on behalf of the second, not the other way around. > > I didn't say "via sudo" > You did mention "sudo" a couple of times. You keep talking about "first" and "second" user, in order to have these you must switch user by some means. sudo, su, perhaps ssh localhost -- can you think of any other means? > I said: the second user (`ghost` in this example) is authorised to act on > behalf of `echo`. > This is an absolutely false expectation. It's not how things are working (and I'm not talking about mc here). The second user does _not_ have access to the first user's belongings. Try sudoing from a normal user to another normal one, and then remove a file of the first user. You'll be denied access. > How it's done is irrelevant. You mentioned PAM. Ok. Let it be PAM. > In that case mc-devel is probably not the right forum to discuss it ;) I admit it sucks on Linux that it's hard to discuss cross-component issues and even much harder to come to an agreement and a followup implementation. > >He has no direct access to the vcsa3 device > > Or she, but anyway they have indirect access via the sticky bit. So it > shouldn't be a problem. > There's no sticky bit in the game, I assume you meant the setuid or setgid bit. I assume you utterly miss the responsibility of a setuid or setgid app. It's _not_ that it is granted tons of permissions via this bit and then can just freely go ahead and do whatever the filesystem's permissions allow them. Due to the setuid/setgid bit, it _becomes_ the responsibility of this helper to explicitly check plenty of conditions to decide whether or not to grant access to the desired device. It would be unacceptable if I could log in to a machine with ssh, and then using the setuid or setgid cons.saver binary I could mess with the consoles that probably root is using locally. cons.saver _must_ explicitly deny this from happening. Maybe the checks it's doing are imperfect, maybe they are a bit too strict or paranoid and could be loosened up, I don't know. (Note: I can't recall ever touching or even examining this code. I'm not defending the particular implementation, I'm defending the overall design.) > Please take a look at my ls -la outputs. Not only is tty3 owened by echo > but it's owned also by the tty group. And as you saw ghost is a pretty > powerful user. The user is a part of the tty group as well. But mc doesn't > care. It also doesn't care whether this is root or not. > It's still unclear to me: What do you expect cons.saver to do differently? > > implementing alternate screen support in the Linux tty driver, or using > a graphical emulator. I can't see how mc could solve this issue. > > That would be overkilling. > No, IMO that would not be overkilling, that would be the proper solution. Also, all other apps (well, their users) would benefit from this: The previous contents would be restored upon quitting from vim, emacs, less and so on. It could be a matter of taste, but I definitely prefer the graphical emulators' behavior here. It makes no sense to me to leave (almost) a screenful of these apps onscreen at an arbitrary position where I happened to stand when I quit, and to lose the last screenful of my bash activity whereas older activity is still accessible with Shift+PageUp. And on a totally irrelevant note (although I'm not sure if I should mention this, I absolutely don't want to initiate a flame war): I personally don't see any reason to use the Linux console over graphical terminal emulators, except for rare critical events. As such, convenience like Ctrl+O after a sudo is absolutely unimportant for me. Systems that don't have graphical environment (that is, servers) should be accessed remotely. Graphical terminal emulators support more features than the Linux console, have a magnitudes larger scrollback that you don't lose when you switch to a different one, can search in the scrollback, look so much nicer, are more configurable, can be arranged freely using your favorite desktop environment, you can see more of them at the same time, you don't have to type your password every time you with to have a new one, let alone you can have other essential apps (e.g. browsers) visible and even copy-paste between them and so on and so forth. (I used to be a heavy Linux console user, even "startx"-ing only for those short times when I needed a graphical app, geez, that was so last century...) Why not just to follow standard *nix conventions? To respect root > privileges at least. May I dare to ask to respect group permissions as well > ;-) > Could you please be more specific? I do not understand what you're _exactly_ asking for. E.g. "respect root privileges" is way too generic, and if I take it as a setuid root cons.saver should allow any user to save/restore the contents of any vcs (that's what root can do anyways) then it's a big fat NO for security reasons. I hope this is clear to you by now. The setuid/setgid bit grants much more to cons.saver that it needs to have, and so it has to deliberately cut back on its own privileges. cheers, egmont -------------- next part -------------- An HTML attachment was scrubbed... URL: From key.offecka at gmail.com Sat Mar 11 23:54:36 2017 From: key.offecka at gmail.com (Key Offecka) Date: Sat, 11 Mar 2017 18:54:36 -0500 Subject: A requirement for the current user to own ttys In-Reply-To: References: <15abeb4fe28.27aa.b35410abedec3f2adbea03ab2b9f751b@gmail.com> Message-ID: Hi, > You did mention "sudo" a couple of times Yes, I did. And maybe even more times, but I never told about extra rights obtained by a user just because of sudoing. > You keep talking about "first" and "second" user, in order to have these you must switch user by some means And I told you, in my test case I use sudo (please mind the *just*) >> sudo here is just used to switch from echo to ghost Once again, sudo is for switching users, access to echo's resources is a different question. > There's no sticky bit in the game, I assume you meant the setuid or setgid bit. Please excuse me, you are totally right, of course it's setuid bit in game here. Sir, I have no explanations why I said 'stick bit'. Demon possession? >> I said: the second user (`ghost` in this example) is authorised to act on behalf of `echo`. > This is an absolutely false expectation. It's not how things are working (and I'm not talking about mc here). The second user does _not_ have access to the first user's belongings. Try sudoing from a normal user to another normal one, and then remove a file of the first user. You'll be denied access. Yes, but mc doesn't delete tty3. So the expectation is not necessarily false. It depends on a particular case. In your example, it's false. But there may be others when it's valid, for example I still can do the following sudo -u ghost bash -c 'echo hello echo >/dev/tty3' just because ghost belongs to the tty group. So by giving the write permission on tty3 to the tty group `echo` authorizes members of the group to write to tty3. It may be not quite correct to say "echo authorizes to act participants of the tty group on behave of them". Sorry for the unclear wording. But you were right I'd got a vague understanding of how it was supposed to work. Thanks to explanations (I really appreciate your wasting time on me) I think I now understand it's also up to the software to handle permissions. > It's still unclear to me: What do you expect cons.saver to do differently? And my suggestions are: if the user (the real user, not the effective one) is root then permission check is successful else if the user owns the resource then permission check is successful else if the user belongs to the group owning the resource then permission check is successful else deny the access > if I take it as a setuid root cons.saver should allow any user to save/restore the contents of any vcs (that's what root can do anyways) then it's a big fat NO for security reasons I agree. > Could you please be more specific? I do not understand what you're _exactly_ asking for. E.g. "respect root privileges" is way too generic By saying respect root permissions I mean that if root runs mc, root should see the background contents and shouldn't press any key after executing commands even though if root doesn't own the tty. > Maybe the checks it's doing are imperfect, maybe they are a bit too strict or paranoid and could be loosened up, I don't know. So, I think the main question here: isn't mc too paranoid? To answer this question we could try answering some more specific questions: How do you think 1) is it OK that in the descried example root has that dumb terminal? 2) if a user doesn't own the tty device but is a member of a group owning the tty, should that user have the dumb terminal? On the both questions personally I answer: no and no. It's not OK that root has the dump terminal, in my opinion it's not OK for a member of the tty group to have the dumb terminal. Off topic: > It could be a matter of taste, but I definitely prefer the graphical emulators' behavior here You are right, it's a matter of taste. > although I'm not sure if I should mention this You shouldn't have to. The same way you could say: to fix the issue don't use mc, use Krusader. -- Best regards, Konstant?n On 11 March 2017 at 16:24, Egmont Koblinger wrote: > Hi, > > On Sat, Mar 11, 2017 at 7:50 PM, Konstantin I. > wrote: > >> Hi, >> >> > Nope. Via "sudo", the first user is allowed to execute certain commands >> on behalf of the second, not the other way around. >> >> I didn't say "via sudo" >> > You did mention "sudo" a couple of times. You keep talking about "first" > and "second" user, in order to have these you must switch user by some > means. sudo, su, perhaps ssh localhost -- can you think of any other means? > > >> I said: the second user (`ghost` in this example) is authorised to act on >> behalf of `echo`. >> > This is an absolutely false expectation. It's not how things are working > (and I'm not talking about mc here). The second user does _not_ have access > to the first user's belongings. Try sudoing from a normal user to another > normal one, and then remove a file of the first user. You'll be denied > access. > > >> How it's done is irrelevant. You mentioned PAM. Ok. Let it be PAM. >> > In that case mc-devel is probably not the right forum to discuss it ;) I > admit it sucks on Linux that it's hard to discuss cross-component issues > and even much harder to come to an agreement and a followup implementation. > > >> >He has no direct access to the vcsa3 device >> >> Or she, but anyway they have indirect access via the sticky bit. So it >> shouldn't be a problem. >> > There's no sticky bit in the game, I assume you meant the setuid or setgid > bit. > > I assume you utterly miss the responsibility of a setuid or setgid app. > It's _not_ that it is granted tons of permissions via this bit and then can > just freely go ahead and do whatever the filesystem's permissions allow > them. > > Due to the setuid/setgid bit, it _becomes_ the responsibility of this > helper to explicitly check plenty of conditions to decide whether or not to > grant access to the desired device. > > It would be unacceptable if I could log in to a machine with ssh, and then > using the setuid or setgid cons.saver binary I could mess with the consoles > that probably root is using locally. cons.saver _must_ explicitly deny this > from happening. > > Maybe the checks it's doing are imperfect, maybe they are a bit too strict > or paranoid and could be loosened up, I don't know. (Note: I can't recall > ever touching or even examining this code. I'm not defending the particular > implementation, I'm defending the overall design.) > > >> Please take a look at my ls -la outputs. Not only is tty3 owened by echo >> but it's owned also by the tty group. And as you saw ghost is a pretty >> powerful user. The user is a part of the tty group as well. But mc doesn't >> care. It also doesn't care whether this is root or not. >> > It's still unclear to me: What do you expect cons.saver to do differently? > > >> > implementing alternate screen support in the Linux tty driver, or using >> a graphical emulator. I can't see how mc could solve this issue. >> >> That would be overkilling. >> > No, IMO that would not be overkilling, that would be the proper solution. > Also, all other apps (well, their users) would benefit from this: The > previous contents would be restored upon quitting from vim, emacs, less and > so on. > > It could be a matter of taste, but I definitely prefer the graphical > emulators' behavior here. It makes no sense to me to leave (almost) a > screenful of these apps onscreen at an arbitrary position where I happened > to stand when I quit, and to lose the last screenful of my bash activity > whereas older activity is still accessible with Shift+PageUp. > > And on a totally irrelevant note (although I'm not sure if I should > mention this, I absolutely don't want to initiate a flame war): I > personally don't see any reason to use the Linux console over graphical > terminal emulators, except for rare critical events. As such, convenience > like Ctrl+O after a sudo is absolutely unimportant for me. Systems that > don't have graphical environment (that is, servers) should be accessed > remotely. Graphical terminal emulators support more features than the Linux > console, have a magnitudes larger scrollback that you don't lose when you > switch to a different one, can search in the scrollback, look so much > nicer, are more configurable, can be arranged freely using your favorite > desktop environment, you can see more of them at the same time, you don't > have to type your password every time you with to have a new one, let alone > you can have other essential apps (e.g. browsers) visible and even > copy-paste between them and so on and so forth. (I used to be a heavy Linux > console user, even "startx"-ing only for those short times when I needed a > graphical app, geez, that was so last century...) > > Why not just to follow standard *nix conventions? To respect root >> privileges at least. May I dare to ask to respect group permissions as well >> ;-) >> > Could you please be more specific? I do not understand what you're > _exactly_ asking for. E.g. "respect root privileges" is way too generic, > and if I take it as a setuid root cons.saver should allow any user to > save/restore the contents of any vcs (that's what root can do anyways) then > it's a big fat NO for security reasons. I hope this is clear to you by now. > The setuid/setgid bit grants much more to cons.saver that it needs to have, > and so it has to deliberately cut back on its own privileges. > > > cheers, > egmont > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egmont at gmail.com Sun Mar 12 00:57:56 2017 From: egmont at gmail.com (Egmont Koblinger) Date: Sun, 12 Mar 2017 01:57:56 +0100 Subject: A requirement for the current user to own ttys In-Reply-To: References: <15abeb4fe28.27aa.b35410abedec3f2adbea03ab2b9f751b@gmail.com> Message-ID: Hi, On Sun, Mar 12, 2017 at 12:54 AM, Key Offecka wrote: > > if the user (the real user, not the effective one) is root then permission > check is successful > else > if the user owns the resource then permission check is successful > else > if the user belongs to the group owning the resource then permission > check is successful > I guess we should also add "and the resource is read-writable by its group" > else deny the access > What do you mean by "the resource" in the lines above? There are at least two pieces of resource in the game, the tty and the vcsa (maybe more, I don't know). We'd need a much more precise description. So, I think the main question here: isn't mc too paranoid? > It could easily be, dunno. > To answer this question we could try answering some more specific > questions: > > How do you think > 1) is it OK that in the descried example root has that dumb terminal? > 2) if a user doesn't own the tty device but is a member of a group owning > the tty, should that user have the dumb terminal? > There are two sides of the story: the user-expected behavior and the technical possibilities. Not sure if the two match here. Normally I'd always put the user-facing behavior first and do the technical bits to implement the expected user-facing behavior. Having a setuid/setgid bit changes the game quite a bit, compromises might become necessary, not having a security hole becomes the number one priority even if the user-facing behavior suffers from drawbacks. What I would say is: If the actual real user has the sufficient access to the tty and vcsa devices even without a setuid/setgid bit (in other words: they could compile and install a modified version of cons.saver for themselves which removes all the current verifications and just tries to operate on the devices and would succeed even without the setuid/setgid bits) then the checks we have in place should not introduce any obstacles. There's no point in denying something that a non-setuid/setgid appication could do. This definitely covers your 1st point. Root should always have access. I am not convinced about the 2nd. On my system (Ubuntu) the vcsa devices belong to the tty group and have read-write perms for this group, so on my system, yes. On your system where these vcsa devices cannot normally be accessed by a member of the tty group _and_ the real user is not the same as the tty's owner, I'm not convinced yet why permission should be granted. Note that there's also the capabilities subsystem which I know nothing about. On the both questions personally I answer: no and no. It's not OK that root > has the dump terminal, in my opinion it's not OK for a member of the tty > group to have the dumb terminal. > This is a heavily security sensitive topic. Any change should be backed up by something stronger than an "in my opinion", any loosening should be thoroughly reviewed, and if there's any doubt, we should err on the side of being paranoid and restrictive rather than risking a security/privacy/dataleakage hole. I'm not against improving the situation at all, but I'd like to see a strong justification behind every requested change, examining why that change cannot be used maliciously much rather than why it solves something on your setup. cheers, egmont -------------- next part -------------- An HTML attachment was scrubbed... URL: From key.offecka at gmail.com Sun Mar 12 18:39:20 2017 From: key.offecka at gmail.com (Key Offecka) Date: Sun, 12 Mar 2017 13:39:20 -0500 Subject: A requirement for the current user to own ttys In-Reply-To: References: <15abeb4fe28.27aa.b35410abedec3f2adbea03ab2b9f751b@gmail.com> Message-ID: Hi, > What do you mean by "the resource" in the lines above? There are at least two pieces of resource in the game, the tty and the vcsa (maybe more, I don't know). We'd need a much more precise description. >> if a user doesn't own the tty device but is a member of a group owning the tty should that user have the dumb terminal? I was talking only about tty devices here. I didn't mention vcs* in any manner. > On your system where these vcsa devices cannot normally be accessed by a member of the tty group _and_ the real user is not the same as the tty's owner, I'm not convinced yet why permission should be granted. Why do you think on my system I cannot access vcs* devices. As far as I remember I never said that. I am sorry if didn't make it clear. On my system cons.saver is owned by the vcsa user and has the setuid bit. vcs* devices are owned by the vcsa user as well, and the user has read/write permissions. Once again, my questions were only about tty devices. I do not know why you're answering questions I never asked. I am not sure if the same security policy should be applied to vcs* devices. All my questions were only about tty since the access to tty devices causes the issue. There are no problems with vcs* on my system, though some improvements of mc may also be needed here. At this moment, as far as I can read the C code, vcs* and tty* devices treated differently. There are no special checks on vcs* done at all. So I believe access to the vcs* is relied only on the OS security. There are special checks on tty and from my perspective they are too paranoid since involve only the user owning devices. || fstat (console_fd, &st) < 0 || st.st_uid != uid || read (vcsa_fd, buffer, buffer_size) != buffer_size console_fd is a tty device here not vcsa As I mentioned, I think groups also should be involved in the checks of tty devices. That's it. Nothing more. Anyway, thank you very much for the discussion. I believe the both sides received all needed information. It's now up to you whether you want to change something in the mc security or not, whether you want to make it less paranoid or not. -- Best regards, Konstant?n On 11 March 2017 at 19:57, Egmont Koblinger wrote: > Hi, > > On Sun, Mar 12, 2017 at 12:54 AM, Key Offecka > wrote: > >> >> if the user (the real user, not the effective one) is root then >> permission check is successful >> else >> if the user owns the resource then permission check is successful >> else >> if the user belongs to the group owning the resource then permission >> check is successful >> > > I guess we should also add "and the resource is read-writable by its group" > > >> else deny the access >> > > What do you mean by "the resource" in the lines above? There are at least > two pieces of resource in the game, the tty and the vcsa (maybe more, I > don't know). We'd need a much more precise description. > > So, I think the main question here: isn't mc too paranoid? >> > > It could easily be, dunno. > > >> To answer this question we could try answering some more specific >> questions: >> >> How do you think >> 1) is it OK that in the descried example root has that dumb terminal? >> 2) if a user doesn't own the tty device but is a member of a group owning >> the tty, should that user have the dumb terminal? >> > > There are two sides of the story: the user-expected behavior and the > technical possibilities. Not sure if the two match here. Normally I'd > always put the user-facing behavior first and do the technical bits to > implement the expected user-facing behavior. Having a setuid/setgid bit > changes the game quite a bit, compromises might become necessary, not > having a security hole becomes the number one priority even if the > user-facing behavior suffers from drawbacks. > > What I would say is: If the actual real user has the sufficient access to > the tty and vcsa devices even without a setuid/setgid bit (in other words: > they could compile and install a modified version of cons.saver for > themselves which removes all the current verifications and just tries to > operate on the devices and would succeed even without the setuid/setgid > bits) then the checks we have in place should not introduce any obstacles. > There's no point in denying something that a non-setuid/setgid appication > could do. > > This definitely covers your 1st point. Root should always have access. > > I am not convinced about the 2nd. On my system (Ubuntu) the vcsa devices > belong to the tty group and have read-write perms for this group, so on my > system, yes. On your system where these vcsa devices cannot normally be > accessed by a member of the tty group _and_ the real user is not the same > as the tty's owner, I'm not convinced yet why permission should be granted. > > Note that there's also the capabilities subsystem which I know nothing > about. > > On the both questions personally I answer: no and no. It's not OK that >> root has the dump terminal, in my opinion it's not OK for a member of the >> tty group to have the dumb terminal. >> > > This is a heavily security sensitive topic. Any change should be backed up > by something stronger than an "in my opinion", any loosening should be > thoroughly reviewed, and if there's any doubt, we should err on the side of > being paranoid and restrictive rather than risking a > security/privacy/dataleakage hole. > > I'm not against improving the situation at all, but I'd like to see a > strong justification behind every requested change, examining why that > change cannot be used maliciously much rather than why it solves something > on your setup. > > > cheers, > egmont > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egmont at gmail.com Sun Mar 12 21:08:13 2017 From: egmont at gmail.com (Egmont Koblinger) Date: Sun, 12 Mar 2017 22:08:13 +0100 Subject: A requirement for the current user to own ttys In-Reply-To: References: <15abeb4fe28.27aa.b35410abedec3f2adbea03ab2b9f751b@gmail.com> Message-ID: Hi, Why do you think on my system I cannot access vcs* devices. As far as I > remember I never said that. > You did include the output of "ls -l /dev/vcs*" on your system, showing that they're owned by vcsa and chmod 600. So, they are not directly accessible to your 'echo' or 'ghost' users. They might be accessible via cons.saver. > I am sorry if didn't make it clear. On my system cons.saver is owned by > the vcsa user and has the setuid bit. vcs* devices are owned by the vcsa > user as well, and the user has read/write permissions. > > Once again, my questions were only about tty devices. I do not know why > you're answering questions I never asked. > > I am not sure if the same security policy should be applied to vcs* devices. > So, again, if I'm not mistaken, cons.saver basically does the following: Based on the ownership, permissions etc. of _/dev/ttyX_, it either grants or denies access to _/dev/vcsaX_. You cannot examine the ttyX and the vcsaX story independently from each other. They are both part of 1 single complex story. Cheers, egmont -------------- next part -------------- An HTML attachment was scrubbed... URL: From egmont at gmail.com Sun Mar 12 21:12:32 2017 From: egmont at gmail.com (Egmont Koblinger) Date: Sun, 12 Mar 2017 22:12:32 +0100 Subject: A requirement for the current user to own ttys In-Reply-To: References: <15abeb4fe28.27aa.b35410abedec3f2adbea03ab2b9f751b@gmail.com> Message-ID: On Sun, Mar 12, 2017 at 10:08 PM, Egmont Koblinger wrote: > So, again, if I'm not mistaken, cons.saver basically does the following: > Based on the ownership, permissions etc. of _/dev/ttyX_, it either grants > or denies access to _/dev/vcsaX_. You cannot examine the ttyX and the vcsaX > story independently from each other. They are both part of 1 single complex > story. > Note: I've not checked the source. This is what I firmly believe cons.saver does, but I might be mistaken. Please correct me if I'm wrong. e. -------------- next part -------------- An HTML attachment was scrubbed... URL: