Subject: Bug#4051: access permissions for /usr/bin/fdmount

From: Daniel Quinlan <[email-masked]>
Date: Mon, 5 Aug 1996 00:43:18 -0400

Package: fdutils
Version: 4.3-3

/usr/bin/fdmount should be mode 4755, not 4750.

---

From: Michael Meskes <[email-masked]>
Date: Fri, 9 Aug 1996 16:33:35 +0200 (MET DST)

> /usr/bin/fdmount should be mode 4755, not 4750.

I agree that the installation is not correct, but I doubt mode 4755 is a
solution. I for one don't like the idea that everyone is able to access my
floppy drive. Since the Debian standard installation for floppy devices is
mode 660 with owner root and group floppy I propose to use the same
owner/group combination for fdmount.

Any comments before I create a new version?

Michael

-- 
Michael Meskes                   |    _____ ________ __  ____
[email-masked] |   / ___// ____/ // / / __ \___  __________
[email-masked]                  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[email-masked]                |  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!                | /____/_/      /_/  /____/\___/_/  /____/

---

From: Daniel Quinlan <[email-masked]>
Date: Tue, 13 Aug 1996 18:37:32 -0400

Michael Meskes <[email-masked]> writes:

> I agree that the installation is not correct, but I doubt mode 4755
> is a solution. I for one don't like the idea that everyone is able
> to access my floppy drive. Since the Debian standard installation
> for floppy devices is mode 660 with owner root and group floppy I
> propose to use the same owner/group combination for fdmount.
>

Use geteuid(2) and/or use a configuration file that says who has
access.  Using permissions alone to dictate who has access to
*running* the binary is bad, IMHO, and I think the Debian package
guidelines agree (unless they've been changed).  Even worse, it's a
`4750' binary in /bin -- so users are getting "permission denied"
errors for something in their path.

Dan

---

From: Michael Meskes <[email-masked]>
Date: Tue, 20 Aug 1996 13:24:44 +0200 (MET DST)

> errors for something in their path.

Okay, I changed that. I will upload a new version once I'm back in the
office (Wednesday).

Michael

---

From: Ian Jackson <[email-masked]>
Date: Thu, 22 Aug 96 00:24 BST

Damn, it looks like my comment
 Before anyone changes anything, please read the appropriate part of
 the new policy manual.
went unheeded.  I see that the change that Daniel Quinlan requested
has been made.  It's a shame that I didn't get around to writing this
more detailed response to the situation sooner.

Daniel Quinlan writes ("Re: Bug#4051: access permissions for /usr/bin/fdmount"):
...
> > Any comments before I create a new version?

There is nothing wrong with having an executable mode 4754 setuid
root, owned by some particular group.  This is the right way to solve
this problem.

> guidelines agree (unless they've been changed).  

The guidelines were ambiguous on this subject.  The new policy manual
is not.  The relevant section, which I wrote before this came up BTW,
says that the access control should be done in the way that it was (I
presume) being done here before.

Compiling names of groups or even worse group ids into binaries is a
bad idea.

>   Even worse, it's a

There is nothing wrong with users getting a `permission denied'
message when they try to do something they are not permitted to,
surely ?

I'm going to reopen this bug report.  Sorry, Michael Meskes (but you
should have heeded my warning).

Sigh,
Ian.

---

From: Michael Meskes <[email-masked]>
Date: Thu, 22 Aug 1996 08:58:00 +0200 (MET DST)

> went unheeded.  I see that the change that Daniel Quinlan requested

Oops.

> more detailed response to the situation sooner.

Yes, I waited for some time without getting one reply.

> root, owned by some particular group.  This is the right way to solve

Aynway the file was in the wrong group.

> Compiling names of groups or even worse group ids into binaries is a

Why? Because it's not easy to change? I talked to Alain (upstream
maintainer) about my changes and he's going to included them into 4.4. I
don't see the problem right now, since you're able to put everyone in group
floppy who shall be able to use fdmount. On the other hand this group coding
(which is ifdef'ed btw so it's not much work to create a new version) adds
security. How many systems have wrong permissions on some files? In
particular a file with s.bit should be as secure as possible IMHO.

> should have heeded my warning).

No problem Ian. But then I'm not so sure if it's a bug now.

Michael

---

From: Ian Jackson <[email-masked]>
Date: Sun, 25 Aug 96 17:08 BST

...
> Why? Because it's not easy to change? 

It's hard to change and obscure.  Policy is best implemented where it
can be seen.

>  I talked to Alain (upstream

Obviously if you've done it right having the binary check itself
whether rgid or getgroups includes `floppy' and having it only
executable by group floppy have the same security effect.

However, there are other differences: having the permissions on the
binary do the enforcement means that a programming error of any kind
in the binary is at most an exposure to group floppy (which may well
be only the sysadmin anyway).  It also makes it much more obvious to
people how to get access.

...
> No problem Ian. But then I'm not so sure if it's a bug now.

We should either change fdmount to match the policy and the other
similar programs (dip, for example), or we should change the policy
and the other programs to match fdmount.

I think that using the file permissions is technically superior, so I
think we should stick with it.

Ian.

---

From: Michael Meskes <[email-masked]>
Date: Sun, 25 Aug 1996 21:42:17 +0200 (MET DST)

> executable by group floppy have the same security effect.

Yes, it checks getgroups.

> people how to get access.

I have no problem with it being mode 4750 again.

> think we should stick with it.

No problem with me. But just in case I let the group check in (since it's in
the upstream source anyway).

I'm preparing a new version.

Michael

---

From: Ian Jackson <[email-masked]>
Date: Tue, 27 Aug 96 14:03 BST

> I have no problem with it being mode 4750 again.

It should be 4754 - there's no point in stopping people reading it.
(I've been saying 4754 all along, and this is what is in the policy
manual.)

...
> the upstream source anyway).

Err, I strongly suggest that you compile the group check out of the
executable.  This is only likely to lead to confusion.

Ian.

---

From: Michael Meskes <[email-masked]>
Date: Wed, 28 Aug 1996 15:09:04 +0200 (MET DST)

> (I've been saying 4754 all along, and this is what is in the policy

Oops, I thought that was a typo :-)

> executable.  This is only likely to lead to confusion.

I think I understand what you mean. But is it really that bad?

Michael

---

From: Ian Jackson <[email-masked]>
Date: Sat, 31 Aug 96 17:41 BST

...
> I think I understand what you mean. But is it really that bad?

Well, how hard is it to compile out ?  It's not the most awful thing
that could happen to a program to have this unnecessary check, but I
do think it will add confusion.

Ian.