gls@novavax.UUCP (Gary Schaps) (04/07/89)
Doe it seem reasonable to try to create an lpr output filter which
selectively prevents certain files from being printed?
--
--------------------------------------------------------------------------------
Gary L. Schaps
P.O. Box 4393 e-mail: gls@novavax.UUCP
Miami Lakes, FL 33014 ...{gatech!uflorida,sun!sunvice}!novavax!glsshirono@hcx3.SSD.HARRIS.COM (04/07/89)
**> comp.unix.wizards gls@novavax.UUCP Apr 6, 1989 <** > Doe it seem reasonable to try to create an lpr output filter which > selectively prevents certain files from being printed? What's the point? You could simply do "cat <file> | lpr". The output filter would then know only that the input comes from stdin. Would you then compare the input to the file(s) you don't want printed? Why is it that you feel the need to prevent these files from being printed? --Roberto ______________________________________________________________________________ || Internet: shirono@ssd.harris.com Roberto Shironoshita || Harris Corporation || ...!novavax---\ Computer Systems Division || UUCP: ...!uunet-------!hcx1!shirono || ...!mit-eddie-/ ------------------------------------------------------------------------------ DISCLAIMER: The opinions expressed here are my own; they in no way reflect the opinion or policies of Harris Corporation.
gls@novavax.UUCP (Gary Schaps) (04/08/89)
In article <48300020@hcx3>, shirono@hcx3.SSD.HARRIS.COM writes: > > **> comp.unix.wizards gls@novavax.UUCP Apr 6, 1989 <** > > Does it seem reasonable to try to create an lpr output filter which > > selectively prevents certain files from being printed? > > What's the point? You could simply do "cat <file> | lpr". The output > filter would then know only that the input comes from stdin. I would like to "protect" certain files by making them "view only". -- -------------------------------------------------------------------------------- Gary L. Schaps P.O. Box 4393 e-mail: gls@novavax.UUCP Miami Lakes, FL 33014 ...{gatech!uflorida,sun!sunvice}!novavax!gls
les@chinet.chi.il.us (Leslie Mikesell) (04/10/89)
In article <1159@novavax.UUCP> gls@novavax.UUCP (Gary Schaps) writes: >> > Does it seem reasonable to try to create an lpr output filter which >> > selectively prevents certain files from being printed? >I would like to "protect" certain files by making them "view only". Not possible if the users are moderately competent. If the user has read access he can use many methods of printing which might circumvent anything you might try to filter out (like reading into an editor and extracting the interesting pieces). The best you could do would be to make the files unreadable by normal users and provide a setuid program that displays the contents only if the output is directly to a terminal. Then you still have to deal with the possibility of hardcopy terminals, printers on the aux port, and PC's emulating terminals with the session being logged to disk or printer. If you don't have dial-up access, perhaps those possibilities would not be a problem but there are still things that might be done with ptys or rlogin sessions back to the same host that would fool your display program. Les Mikesell
kremer@cs.odu.edu (Lloyd Kremer) (04/11/89)
In article <8185@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >*In article <1159@novavax.UUCP> gls@novavax.UUCP (Gary Schaps) writes: >*>> > Does it seem reasonable to try to create an lpr output filter which >*>> > selectively prevents certain files from being printed? >* >*>I would like to "protect" certain files by making them "view only". > >................................... The best you could do would be >to make the files unreadable by normal users and provide a setuid program >that displays the contents only if the output is directly to a terminal. Even this can be tricky to get right in all cases. I just ran this program on our AT&T 3B2 running UNIX(tm) System V Release 3: #include <fcntl.h> main() { int fd; if((fd = open("/dev/tty15", O_WRONLY)) != -1){ printf("isatty() returns %d\n", isatty(fd)); close(fd); } return(0); } It produced: isatty() returns 1 On our system, /dev/tty15 is a NEC Pinwriter P2 parallel printer. Not all "ttys" are real terminals. Lloyd Kremer Brooks Financial Systems {uunet,sun,...}!xanth!brooks!lloyd
kremer@cs.odu.edu (Lloyd Kremer) (04/12/89)
In article <8185@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >*In article <1159@novavax.UUCP> gls@novavax.UUCP (Gary Schaps) writes: >*>> > Does it seem reasonable to try to create an lpr output filter which >*>> > selectively prevents certain files from being printed? >* >*>I would like to "protect" certain files by making them "view only". > >................................... The best you could do would be >to make the files unreadable by normal users and provide a setuid program >that displays the contents only if the output is directly to a terminal. This could be made even more secure by displaying not to just *any* terminal, but specifically to /dev/tty. How about this? : Create a pseudo-user, say "viewer". Block the login sequence for this pseudo-user. Make all view-only files mode 400 viewer. Write an executable (not a shell-script) that just opens /dev/tty if possible, and copies the requested file(s) to it. Screen pagination would be a nice touch (--MORE--). Make the executable setuid viewer. This would (hopefully) discourage all users except those resourceful enough to change their process's controlling tty before running the executable. Take care that the executable does not utilize on any other program such as vi, ex, ed, etc. The user could then write the buffer anywhere by means of ':w ! lpr', or something similar. This is no doubt still circumventable somehow, since one of UNIX's great strengths is the ability to redirect and pipe anything anywhere, but it might be useful as a starting point. Lloyd Kremer Brooks Financial Systems {uunet,sun,...}!xanth!brooks!lloyd
heather@maui.cs.ucla.edu (Heather Burris) (04/12/89)
In article <1159@novavax.UUCP> gls@novavax.UUCP (Gary Schaps) writes: >I would like to "protect" certain files by making them "view only". I can understand why you would want to do that, because I have had occasion to make documents available to students on computer for viewing but restricted from printing either because of copyright problems or, more likely, paper restrictions. The easiest way I know to do it is allocate a userid to own the documents (e.g. userid 'document') and to front-end access to the files with setuid 'document' programs that would allow the access you want. Therefore you could provide a script that would allow one to simply list, view and search the documents and nothing else. You have to be careful, though, with standard UNIX programs like 'more' which might allow a user to slip into vi and then save the output to another file which could then be printed. There is no standard protection mode within the UNIX filesystem that would do what you want, however. 'Read' access allows reading for any purpose, including printing. Heather Burris, UCLA
chris@mimsy.UUCP (Chris Torek) (04/12/89)
The discussion is really about `files that can be viewed on a terminal but not printed'. It is worth noting that this effort is doomed to failure, as there are terminals that are printers, or have integral printers. If you have physically secure terminals, you could set something up so that the files can be viewed only on /dev/ttyA2, /dev/ttyh0, and so forth. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
aida@porthos.csl.sri.com (Hitoshi Aida) (04/13/89)
In article <16878@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >The discussion is really about `files that can be viewed on a terminal >but not printed'. > >It is worth noting that this effort is doomed to failure, as there >are terminals that are printers, or have integral printers. > So, there is no perfect solution, but usually it is sufficient if making hard-copy is difficult enough. How about this: as discussed early, make a special uid that can access the files. Make a set-uid program which looks the termcap and display the content of the file in special manner. For example, use cursor motion to write characters in random order, produce different style of output (e.g. different number of columns in multi-column output) on each page to make the collection of "screen dump" difficult, and so on. Of course it should refuse to show the file if the terminal looks like a printer (i.e. lacks some basic terminal capabilities). -------- Hitoshi AIDA (aida@csl.sri.com) Computer Science Laboratory, SRI International
pme@io.UUCP (Paul English x3168) (04/13/89)
Re: using the special user `viewer' approach, with the desired files owned by `viewer', and mode 400. What if I first run `script', then use the viewer setuid program to view the files? I would then have the output in `typescript'. Or, if a run a terminal emulator with memory (like xterm, or cmdtool), I can just cut and paste the window output to another window/file.
ok@quintus.UUCP (Richard A. O'Keefe) (04/13/89)
In article <9712@cslb.CSL.SRI.COM> aida@csl.sri.com (Hitoshi Aida) writes: >In article <16878@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>The discussion is really about `files that can be viewed on a terminal >>but not printed'. >So, there is no perfect solution, but usually it is sufficient if making >hard-copy is difficult enough. How about this: as discussed early, make >a special uid that can access the files. Make a set-uid program which >looks the termcap and display the content of the file in special manner. How to crack the proposed solution: (1) Write a terminal emulator that reads characters and escape sequences and builds screen images. (2) Use 'script' to capture the bytes written by the program ('script' looks to the program like a tty). Other operating systems have similar hooks, e.g. COMOUTPUT in PR1MOS, PHOTO in some DEC systems. (3) Feed result of (2) into result of (1). Seriously, if there is some information you want people to be able to get at, but not to make off with, why not put it on microfiche and have a 'fiche reader in the room? If you think that would be too expensive, then you don't care about keeping the data inside as you thought you did. For better security than that, print one hard-copy, and put it in your library as a desk copy. Heck, what's to stop someone copying the stuff off the screen with a camera, or even writing it down by hand? At least providing the information on 'fiche will make it look as though you are trying to _provide_ the information...
klg@dukeac.UUCP (Kim Greer) (04/13/89)
In article <16878@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
++The discussion is really about `files that can be viewed on a terminal
++but not printed'.
++
++It is worth noting that this effort is doomed to failure, as there
++are terminals that are printers, or have integral printers.
++
++If you have physically secure terminals, you could set something up
++so that the files can be viewed only on /dev/ttyA2, /dev/ttyh0, and
++so forth.
++--
++In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
++Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
I think Chris is right; it is doomed. Even "secure" terminals can
run "script" to capture the screen output and then immediately print
the typescript file. You don't have script on your system? A pd
version is available.
--
Kim L. Greer
Duke University Medical Center try: klg@orion.mc.duke.edu
Div. Nuclear Medicine POB 3949 dukeac!klg@ecsgate
Durham, NC 27710 919-681-2711x223 ...!mcnc!ecsgate!dukeac!klg fax: 919-681-5636bernsten@phoenix.Princeton.EDU (Dan Bernstein) (04/15/89)
In article <1347@dukeac.UUCP> klg@dukeac.UUCP (Kim Greer) writes: > In article <16878@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > ++The discussion is really about `files that can be viewed on a terminal > ++but not printed'. > ++It is worth noting that this effort is doomed to failure, as there > ++are terminals that are printers, or have integral printers. > ++If you have physically secure terminals, you could set something up > ++so that the files can be viewed only on /dev/ttyA2, /dev/ttyh0, and > ++so forth. > I think Chris is right; it is doomed. Even "secure" terminals can > run "script" to capture the screen output and then immediately print > the typescript file. You don't have script on your system? A pd > version is available. Chris is correct that the only way to ensure that a file is viewed but not printed is through a direct connection to a physical terminal that does not allow printing. So you could set up a setuid program that checks the inode of fd 1 and only sends output if the inode matches one of the physically secure ttys. script most certainly does not defeat this, as it allocates a pseudo-terminal, which can't pretend to be a different inode any more than ``| tee output'' can. No government standard for security that I know of allows ``viewing but not printing''; has nobody heard of screen-adjusted cameras? I don't understand what purpose the original poster had in mind. ---Dan Bernstein, bernsten@phoenix.princeton.edu
Kemp@DOCKMASTER.NCSC.MIL (04/19/89)
>> Does it seem reasonalble to try to create an lpr output filter which >> selectively prevents certain files from being printed? > > I would like to "protect" certain files by making them "view only". No, it is totally unreasonable to do what you ask, unless you 1) are going to restrict users to ADM-3 terminals with tamperproof cables, or 2) are only interested in saving paper on your printer, not with protecting the information in your files. Consider: Any user on a serial line could just wire a printer in parallel with the terminal line. All micro based terminal emulator programs let you log output to a file. Output directed to a SunView shell window can be cut and pasted into another shell or edit window. The semi-dumb terminal I am typing on now (a Tektronix 4107) has 1500 lines of memory and a printer port. (You should get the idea by now). If the user can see the information, he can save it, and print it, no matter how clever your viewer program is. (If all else fails, he could photograph the screen.) This should be obvious. Dave Kemp <Kemp@dockmaster.ncsc.mil>