hpoj?
Tom London
selinux at comcast.net
Tue Jul 20 16:19:31 UTC 2004
From what I understand, ptal implements the mechanism
to connect to bidirectional printers/scanners/....
In my case, I have a USB connected HP office
jet (an HP PSC-950). I'm guessing it scans
through /proc/bus/usb to discover appropriate
devices.
I made the change you suggested (adding 'allow' for etc_t
and etc_runtime_t), and did a 'make install'.
'run_init /etc/rc.d/init.d/hpoj start' now gets
a quick 'denied' when attemping to create the socket
('usb:PSC_900_Series'):
Jul 20 07:17:56 fedora kernel: audit(1090333076.788:0): avc:
denied { create } for pid=3684 exe=/usr/sbin/ptal-mlcd
name=usb:PSC_900_Series scontext=system_u:system_r:ptal_t
tcontext=system_u:object_r:var_run_t tclass=sock_file
Jul 20 07:17:56 fedora ptal-mlcd: FATAL ERROR at ExMgr.cpp:1250,
dev=<mlc:usb:PSC_900_Series>, pid=3684, e=13, t=1090333076
bind(/var/run/ptal-mlcd/usb:PSC_900_Series) failed! Ensure
/var/run/ptal-mlcd/ exists.
The above shows ptal failing to create sock-file
'/var/run/ptal-mcld/usb:....').
(Shouldn't the tcontext be 'ptal_var_run_t'????)
Jul 20 07:17:56 fedora kernel: audit(1090333076.799:0): avc:
denied { search } for pid=3685 exe=/usr/sbin/ptal-printd name=root
dev=hda2 ino=1196033 scontext=system_u:system_r:ptal_t
tcontext=root:object_r:staff_home_dir_t tclass=dir
I don't know why ptal is trying to seach '/root'.
Jul 20 07:17:56 fedora kernel: audit(1090333076.800:0): avc:
denied { read } for pid=3685 exe=/usr/sbin/ptal-printd
name=mlc:usb:PSC_900_Series dev=hda2 ino=738368
scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:etc_t
tclass=file
'find / -inum 738368' -> /etc/ptal/mlc:usb:PSC_900_Series
-rw-rw---- root lp system_u:object_r:etc_runtime_t
ptal-printd-like
Jul 20 07:17:56 fedora kernel: audit(1090333076.800:0): avc:
denied { getattr } for pid=3685 exe=/usr/sbin/ptal-printd
path=/etc/ptal/ptal-printd-like dev=hda2 ino=737289
scontext=system_u:system_r:ptal_t
tcontext=system_u:object_r:etc_runtime_t tclass=file
Jul 20 07:17:56 fedora ptal-printd:
ptal-printd(mlc:usb:PSC_900_Series): Unable to read file permissions
from "/etc/ptal/ptal-printd-like"!
Jul 20 07:17:58 fedora ptal-photod:
ptal-photod(mlc:usb:PSC_900_Series) successfully initialized, listening
on port 5703.
One of the 'ptal' daemons has started, but others have not.
tom
Russell Coker wrote:
>On Tue, 20 Jul 2004 03:15, Tom London <selinux at comcast.net> wrote:
>
>
>>Audit2allow on permissive avc's yield:
>>allow ptal_t etc_runtime_t:file { getattr };
>>allow ptal_t etc_t:file { read };
>>
>>
>
>For file access whenever read access is requested you should allow getattr.
>For a file type such etc_runtime_t which contains nothing secret if you allow
>getattr you should allow read. So I added the following to my tree:
>
>allow ptal_t { etc_t etc_runtime_t }:file { getattr read };
>
>
>
>>allow ptal_t staff_home_dir_t:dir { search };
>>
>>
>
>What does ptal do? Why does it need such access?
>
>
>
>>allow ptal_t usbdevfs_t:dir { getattr read };
>>
>>
>
>Again, what is it trying to do here? I've never used ptal so I don't know
>what we should be permitting it to do.
>
>
>
>>allow ptal_t var_run_t:fifo_file { create read setattr };
>>allow ptal_t var_run_t:sock_file { create setattr };
>>
>>
>
>For the sock_file and the fifo_file in question you didn't provide enough
>information to determine which directory they are in. Please repeat the
>tests and use "find /var/run -inum ..." to find the full path.
>
>If they are under /var/run/ptal-printd or /var/run/ptal-mlcd then they should
>have the correct type and there should not be any problem (in which case
>there is some strange mis-labelling issue). If they are not under those
>directories then I will need to know the directories that they are in to
>write the correct policy.
>
>
>
More information about the fedora-selinux-list
mailing list