Re: Audio Apps Mini-Policy, v0.1
On Tue, Oct 28, 2003 at 11:47:49AM +0000, Steve Kemp wrote:
> On Tue, Oct 28, 2003 at 09:43:07PM +1100, Zenaan Harkness wrote:
>
> > Audio applications or applets (ie. executable files) requiring realtime
> > privileges should be installed as follows:
> > - user = root
> > - group = audio
> > - permissions
> > - SUID root
> > - have a debconf question asking to allow/ deny this
> > - [debconf question "importance level"??]
> > - user = read, write, execute
> > - group = read, execute
> > - other = read only
>
> Why read only for other? Given that they can't execute what is
> presumably a compiled binary I'd treat them as untrusted and not allow
> them to read it at all.
Why? Quoting policy because I can't reason better: "They should not be made
unreadable [...]; doing so achieves no extra security, because anyone can find
the binary in the freely available Debian package; it is merely inconvenient.
For the same reason you should not restrict read or execute permissions on
non-set-id executables."
[...]
> > Finally, installation of such applications should (should they really?)
> > check for the local machine's administrator's perms/ ownership overrides
> > (specified by dpkg-statoverride) similar to as follows:
> I thought the point of stat override was that this happened without
> any extra effort on the part of the package being installed?
It depends, for the general szenario where just ship a file with the
intended permissions in the deb, and almost nobody would change them
that is correct, those crazy people use dpkg-statoverride and
everybody else has to do nothing.
However if a big portion of people want to have permission-set A and
another big portion of people want permission-set B, it gets
difficult.
The easiest way out is to say "Ship with (the safer) permission-set A,
and everbody else has to read README.Debian and execute
dpkg-statoverride by themself."
If you decide to allow selecting permissions with debconf at
install-time via debconf you have to take care of dpkg-statoverride
one way or the other:
#1: check whether the admin has used dpkg-statoverride himself, and in
that case do nothing (don't ask), because the admin has taken care
of the issue. Otherwise use use chmod to modify the permissions.
#2: Always ask and execute dpkg-statoverride according to the given
answer.
#2 is not easier to implement but a lot less flexible, as it takes
dpkg-statoverride out of the local admins scope.
> > Anyone, how does Andreas' comment "We _do_ have an audio-group and users
> > who need to have access to /dev/{mixer,snd,dsp,..} should be put in
> > there, instead of making the app SGID." apply here - ie. am I confused
> > about the use of SUID?
> I think that the SGID would be fine if it were just a matter of
> reading/writing audio devices. However in the case of tools that need
> realtime priority you'll need SUID to do this. If you're SUID already
> then being SGID(audio) is redundent.
Yes, I misunderstood the issue at hand.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
Reply to: