Read only account

[D. Rus Savary]

Is is possible to establish a "read only" account on HP? The purpose would be to allow an audit of change from a disinterested or unbiased person. With an account that just allowed read-only access, that individual could look anywhere on a system to see if a change had been implemented, but we could guarentee that that person could not tamper with the server.

[Pete Randall]

I don't think so - permissions are controlled at the file/directory level and apply to all users.

Pete

[Sridhar Bhaskarla]

Hi Rus,


Create a shell script that will allow the person to view (not vi) only the configuration files. Make it as his/her default shell.

Or you can use SUDO.

[Sajid_1]

hello,

May be you should read about sudo: http://www.courtesan.com/sudo/

[doug hosking]

It's hard to say what's best without
knowing a lot more about your environment
and goals. Is your primary goal for something like production/quality control or for security analysis? Depending on the answer,
many of the following might not apply, but
I can't tell what your real goals are.

The 'view' reply needs to consider that
view has a shell escape (:!sh), which could
presumably be used to alter some files.

The sudo idea might work, combined with cat.(i.e. you can make a copy of any file,
into some scratch directory by running cat under sudo, then browse the file at leisure.) Combining sudo and cp would probably not be a good idea, because that would give them privilege not only for the source file but also the target file.

What is the nature of the change verification?
Is it enough to know the names, dates and checksums of files or do they actually have to look at the contents of the files to verify
the changes? I could imagine a daily cron
job that did
'find / -type f -print | xargs cksum > log_file 2>&1'
and making such a log file available by
anonymous ftp, mail, NFS export, etc. With minor changes you could add 'ls -lRt /' or
similar to the cron job to be able to see file names, sizes change dates,
permissions, etc. That might work well
for production control purposes. It's
probably not sufficient if the goal is
for generic security audits.

Other possibilities would include NFS-exporting
a read-only copy of everything (or key
directories) but that's
likely to have some practicality and security
issues in most environments. (also perhaps
file permission problems)

If you're concerned about a fairly well
defined set of files that's expected to be
constant across a number of machines,
not concerned about malicious attempts to
bypass the system, and just want to identify inconsistencies, something like 'rdist -v' might be helpful.

You might also look at www.tripwire.com.