Scott,
Thanks for your input.
Comments embedded below.
Margot
Scott Rotondo wrote:
> Margot Miller wrote:
>> If rmt is not setuid, nor does it re-exec via pfexec, would the
>> auditing of rmt
>> still be required? The goal is not to diverge much from Joerg's
>> source base.
>
> Ken said in another email that rmt does not run with privilege,
> acquired via setuid or pfexec. Can I also assume that there is no
> daemon running as root?
Joerg, Ken, can you please confirm?
>
> Assuming that the answer is yes, and rmt really is unprivileged, there
> seems to be no need to audit. However, it would also seem that the
> access control system described in /etc/default/rmt does absolutely
> nothing. Are we sure we understand how this program works?
It look to me like it was actually just limiting access.
Below is the man page documentation of it:
/etc/default/rmt
Default values can be set for the following options in
/etc/default/rmt. For example:
DEBUG=/tmp/rmt.debug
USER=tape
ACCESS=tape myhost.mydomain.org /dev/rmt/*
All keywords must be on the beginning of a line.
DEBUG
If you like to get debug information, set this to
a file name where rmt should put debug informa-
tion.
USER The name of a user (local to the magnetic tape
server) that may use the services of the rmt
server. More than one USER=name line is possible.
A line USER=* grants access to all users.
ACCESS
This keyword is followed by three parameters
separated by a TAB. The name of a user (local to
the magnetic tape server host) that may use the
services of the rmt server followed by the name of
a host from where operation is granted and a file
specifier pattern for a file or file sub tree that
may be accessed if this ACCESS line matches. More
than one ACCESS=name host path line is possible.
If standard input of rmt is not a socket from a
remote host, rmt will compare the host entry from
/etc/default/rmt with the following strings:
PIPE If stdin is a UNIX pipe.
If you like to allow remote connections
that use the ssh protocol, you need to
use the word PIPE instead of thr real
hostname in the matching ACCESS= line.
ILLEGAL_SOCKET
If getpeername() does not work for
stdin.
NOT_IP If getpeername() works for stdin but is
not connected to an internet socket.
>
>>
>> The project team has agreed that if this is a requirement, then we have
>> a few options:
>>
>> 1) We could just not ship /etc/default/rmt.
>>
>> 2) We could ship the /etc/default/rmt file with the below contents:
>>
>
> Changing or removing /etc/default/rmt wouldn't make a difference.
> After all, it's a configurable interface and the customer could put
> back whatever contents we remove, right?
Yes, that is true. My thought was that if we didn't document it
and it was a private interface,
then it would not a supported configuration if the customer
created one or modified the
existing one on the system (especially if the file said "DO NOT
EDIT").
But I am sure there would be some savvy star users who had been
using star for awhile
and would know about the existence of the file and know how to
create it/and or modify it.
>
> The point is that we're inferring from the sample config file that the
> rmt code makes access control decisions (since those decisions are
> configured in the file). It's the presence of the code, not the
> particular configuration file, that leads to the audit requirement.
That would bring up another option- not ship the file and disable
the feature in the code.
>
> Scott
>
>
