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 selinux mailing list