[2513] in Enterprise Print Delivery Team
Re: Fwd: Problems Saving Unauthorized LPR Jobs to Restricted
daemon@ATHENA.MIT.EDU (Susan Starr)
Tue Jun 25 14:02:31 2002
Message-Id: <5.0.2.1.2.20020625135309.00aeec78@hesiod>
Date: Tue, 25 Jun 2002 13:59:35 -0400
To: tregan@MIT.EDU
From: Susan Starr <sstarr@MIT.EDU>
Cc: IPM-SYS <IPM-SYS@mitvma.mit.edu>, printdel@MIT.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Theresa,
In hopes of addressing concerns about the acl for GL Statements, we have
had a meeting with Garry Z, in which he agreed to automate generation and
downloading of the file(s) by the end of July. We also discussed putting
control of the user lists in the hands of the manager (in this case, Gill
Emmons I think). So, with a three-hour lead time, a new user could have
printing permissions on the GL queues.
I understand the concern about the infrequency of new users being added to
the list, and the difficulty involved in remembering to update the
list. Perhaps we should include Gill in the discussion of this issue and
what can be done to prompt a list addition. There is a need to provide
adequate security on the print servers, which makes the "unrestricted
front-end queue" idea somewhat dangerous. By the time the filter is
applied, the job has already made it past the initial connection
point. Under the current setup, connection to the machine is allowed, but
a restricted-queue job is rejected before filtering if the user name is not
on the acl named in lpd.perms for the queue. The second-tier security is
checking the incoming IP against a list of MIT masks.
Your suggestion to have the operators release the GL job(s) at a particular
time is something which could be done, but does not address the general
security needs of the system. It seems to me that the same degree of care
could be applied to ensuring that users have been added to a user list,
maintained by their own group. IAST will be happy to work with the
affected groups to ramp up this process, as well as issue reminders prior
to print dates if necessary.
I'd be happy to talk to you further about this; I am still in the learning
phase, and I am extremely interested in your perspective.
Thanks,
Sue Starr
At 05:48 AM 6/17/2002 -0400, Theresa M Regan wrote:
>Hi Dave,
>
>Thank-you for pointing out this e-mail and the clarification that Rockyln
>and Garry have provided with regard to the relationship between "moira"
>and LPRng.
>
>For the "restricted" queues that I am aware of, there is an additional
>precaution/complexity since there is application level access control, as
>well. Very few people are allowed/expected to run these types of jobs
>which generate print requests for these queues. I am confident that the
>all the critical relationships could be set-up accurately (initially). It
>is the on-going maintenance that is a concern.
>
>Is the solution a "non-technical" solution?
>For now, the restricted queue that I am aware of is the GL Statements. Do
>we go forward with the implementation and the risk that GL statements will
>be rejected if the userid in not in the acl in "moira"? Do we
>clarify/emphasize to the business owners (Gill Emmons) and R3-admin that
>when anyone in addition to Gill, Jay Nickerson, etc. are granted
>authorizations to execute the GL Statements, they need to be on the moira
>acl for that queue, as well. If they are not, their print job will be
>rejected and need to be re-run? (This print job is too large to leave it
>on the R3 servers for 48 hours which may be a solution in other scenarios.)
>
>Or, accept that if a print job hits the GL Statement queue, it is expected
>to be printed. For the operators, by chance, are there additional
>relevant pieces of data which could be captured from the originating print
>request for a decision to print or not. Example: generally, we know when
>to expect the statements. If a print request arrives in the queue and it
>is not expected, a set of procedures is followed? If we are expecting a
>print job and it arrives on-time, there may be still a few other details
>possibly to check out... verification that the print request originated
>from SAP R/3.
>
>Sorry, I have not been able to come up with other ideas or simpler
>ones. One of the challenges with the proposed restricted queues and that
>we anticipate their maintenance to be infrequent. If the business
>applications tied to restricted queues experienced frequent changes in
>personnel, there would be less of a risk of just rejecting the print
>request and the business owner would be fully aware of the impact of the
>decision and coordination of the data.
>
>Thanks,
>Theresa
>
>
>>Date: Thu, 30 May 2002 14:32:46 -0400
>>To: Enterprise Printing Delivery Team <PRINTDEL@mit.edu>
>>From: "Rocklyn E. Clarke" <rclarke@MIT.EDU>
>>Subject: Problems Saving Unauthorized LPR Jobs to Restricted IPM Queues
>>Cc: IPM-SYS <IPM-SYS@MITVMA.MIT.EDU>, "Regan,Theresa M" <tregan@mit.edu>
>>
>>Hi Team,
>>
>>As you know, we plan to automatically download Moira printcap information
>>to LPRng running on the IPM servers. We would also like to make use of
>>LPRng's ability to restrict selected print queues so that only authorized
>>job users can submit jobs through them. Furthermore, we have a business
>>requirement that a job submitted to a restricted queue by an unauthorized
>>user be saved in case the job is one that really should be printed.
>>
>>Last week I raised a concern with this plan based on my understanding of
>>LPRng which Garry has now confirmed (see his email below). If we attempt
>>to download from Moira a list of authorized users for a print queue,
>>LPRng will reject lpr submissions from unauthorized users WITHOUT giving
>>us a chance to grab the print job and save it anywhere.
>>
>>In order to implement restricted queues, we would need to download a list
>>of authorized users to a non-standard file (i.e. NOT /etc/lpd.perms) and
>>IMPLEMENT OUR OWN LOGIC for checking ALL lpr jobs for ANY print queue
>>against a new internal list of restricted queues and authorized users.
>>
>>Obviously this is would be a significant departure from our strategy of
>>paralleling as much as possible the structure of the Athena Print
>>Services implementation. It would also create more potential points of
>>failure for our printer service. There may very well be a way to save
>>print jobs from unauthorized users without incurring these disadvantages,
>>but nothing elegant springs immediately to mind for me. I'm willing to
>>give this some more thought, but since I don't have as much time to
>>devote to this as I used to, I want to give everyone else out there a
>>chance to come up with something.
>>
>>Rocklyn
>>
>>P.S. Something inelegant: It occurs to me that we could "front-end" a
>>restricted queue with an unrestricted queue and "trap" rejected jobs in
>>the middle. This would add an unfortunate amount of complexity, but
>>perhaps it would work. I'll let Garry weigh in on it.
>>
>>At 5:32 PM -0400 5/21/02, Garry Zacheiss wrote:
>>> >> Do you have any alternatives to suggest?
>>>
>>> No; if you want this feature, you'll need to implement your
>>>authorization in the filter.
>>>
>>>Garry
Susan Starr
Information Systems
Infrastructure Services
W91-205b
Office: 617-253-6639
Cell: 978-821-9459
Susan Starr
Information Systems
Infrastructure Services
W91-205b
Office: 617-253-6639
Cell: 978-821-9459
