[cups] Question about CUPS 1.6.3 on RHEL SELINUX 7.0 (Presently "Permissive")
Kevin King
kevin at precisonline.com
Mon Feb 23 08:37:38 PST 2015
This issue is resolved. The issue was a new security feature of RHEL 7
called "PrivateTmp". This feature allows configured system services to run
with a privately mounted /tmp that is different from the actual "/tmp"
directory. This feature mounts its own /tmp directory for the service and
discards it when the service exits.
In /usr/lib/systemd/system there is a file called cups.service. In here,
in the [Service] stanza, PrivateTmp was set to true. Changing it to false
has resolved the issue. Now we need to better understand if we want to
keep these files in /tmp or if we want to move them elsewhere. Based on
security best practices, it seems like we may want to move the files to
$TMPDIR instead.
-K
On Mon, Feb 23, 2015 at 9:15 AM, Kevin King <kevin at precisonline.com> wrote:
> To test lp security I set a password and logged in as the lp user and it
> has full write permissions to /tmp and /tmp/spool in the present
> configuration. The only issue seems to be with this interface script
> running under CUPS. I did find some reference on the web about certain
> operating systems have additional security built into CUPS - the article in
> particular mentioned OS X - and was wondering if there is some additional
> configuration in CUPS that causes scripts to be limited to outputting to
> certain directories. Is there such a configuration or limitation on RHEL?
>
> -K
>
> On Mon, Feb 23, 2015 at 7:20 AM, Kevin King <kevin at precisonline.com>
> wrote:
>
>> I have tried with SELINUX both disabled and in permissive mode with no
>> change. In either of these configurations does it not rule out SELINUX as
>> being the cause? Is CUPS using the enhanced security even when it has been
>> disabled? We have this working on other SELINUX systems in permissive mode.
>>
>>
>> On Monday, February 23, 2015, Helge Blischke <helgeblischke at web.de>
>> wrote:
>>
>>> You need to investigate the following SELinux settings:
>>> 1. Check out what SELinux user is associated with the operating
>>> system user „lp“.
>>> 2. Check the role, objects and rules defined for that SELinux user
>>> 3. Modify the rules/objects to make your destination directory
>>> accessible
>>> (writable) for this SELinux user.
>>>
>>> Note that a modification like this might be repeated after system
>>> updates.
>>>
>>>
>>> > Am 23.02.2015 um 00:32 schrieb Kevin King <kevin at precisonline.com>:
>>> >
>>> > The problem I'm having isn't really a printer, but rather a script that
>>> > I've setup to print to a file. We use this script on all our Linux
>>> systems,
>>> > but this is the first time on RHEL 7. The script is an interface
>>> script
>>> > for a printer (0) that just copies a file from the spool directory to
>>> a tmp
>>> > directory.
>>> >
>>> > #!/bin/ksh
>>> > # This printer will output the spooler job to /tmp/spool.
>>> >
>>> > ENTRY=$1
>>> > USER=$2
>>> > FILE=$6
>>> > NEWFILE=/tmp/spool/${USER}-${ENTRY}
>>> >
>>> > echo cp ${FILE} ${NEWFILE} >&2
>>> >
>>> > cp ${FILE} ${NEWFILE}
>>> > chmod 777 ${NEWFILE}
>>> >
>>> > exit 0
>>> >
>>> > This was then created as a printer 0 using this:
>>> >
>>> > lpadmin -p 0 -v file:/dev/null -i /tmp/0
>>> >
>>> > (/tmp/0 is this script.)
>>> >
>>> > Note how all this does is copy the CUPS spooler entry to /tmp/spool and
>>> > give it a name of "user-job#". I have an extra "echo" in there for
>>> testing
>>> > but that's inconsequential.
>>> >
>>> > /tmp exists. /tmp/spool exists. Both are wide open in terms of
>>> permissions:
>>> >
>>> > sh-4.2# ls -ld /tmp /tmp/spool
>>> > drwxrwxrwt. 23 root root 4096 Feb 21 18:38 /tmp
>>> > drwxrwxrwx 2 root root 6 Feb 21 18:38 /tmp/spool
>>> >
>>> > I should note that the script runs fine - no errors - when run outside
>>> of
>>> > the context of CUPS. It also runs in CUPS 1.7.2 on an Ubuntu system
>>> and on
>>> > CUPS 1.4.2 on RHEL.
>>> >
>>> > In CUPS, however, here's what happens (from the error_log in CUPS)
>>> First
>>> > up, here's the output of the first echo that I added to show the
>>> command
>>> > that is about to run:
>>> >
>>> > D [21/Feb/2015:18:26:47 -0500] [Job 60] cp /var/spool/cups/d00060-001
>>> > /tmp/spool/root-60
>>> >
>>> > And then this:
>>> >
>>> > D [21/Feb/2015:18:26:47 -0500] [Job 60] cp: cannot create regular file
>>> > '/tmp/spool/root-60': No such file or directory
>>> > D [21/Feb/2015:18:26:47 -0500] [Job 60] chmod: cannot access
>>> > '/tmp/spool/root-60': No such file or directory
>>> >
>>> > This appears to be telling me that CUPS interface scripts (presently
>>> > configured to run as the lp user) has no visibility to the /tmp
>>> directory.
>>> > I've also tried updating a log with:
>>> >
>>> > echo "i am here" > /tmp/out.log
>>> >
>>> > But nothing ever shows up, as if /tmp is entirely missing.
>>> >
>>> > I've gone as far as to enable the lp user to login so that I could
>>> verify
>>> > that it can see and write to the /tmp/spool directory. The lp user
>>> can see
>>> > the /tmp and /tmp/spool directories, and can write freely to them. So
>>> it
>>> > doesn't appear to be a limitation to permissions or that specific user.
>>> >
>>> > But what could it be? I'm running out of options to check. This exact
>>> > script works brilliantly on RHEL 6.6/CUPS 1.4.2 and also on Ubuntu
>>> 14.04
>>> > LTS/CUPS 1.7.2. On this one system, however, it's as if /tmp just
>>> doesn't
>>> > exist.
>>> >
>>> > Any ideas?
>>> >
>>> > -K
>>> > _______________________________________________
>>> > cups mailing list
>>> > cups at cups.org
>>> > https://www.cups.org/mailman/listinfo/cups
>>>
>>> _______________________________________________
>>> cups mailing list
>>> cups at cups.org
>>> https://www.cups.org/mailman/listinfo/cups
>>>
>>
>>
>> --
>> -K
>>
>>
>
More information about the cups
mailing list