* append_lnk_files_pattern
@ 2023-09-30 11:55 Russell Coker
2023-10-02 12:40 ` append_lnk_files_pattern Chris PeBenito
0 siblings, 1 reply; 2+ messages in thread
From: Russell Coker @ 2023-09-30 11:55 UTC (permalink / raw)
To: selinux-refpolicy
Why do we have the pattern append_lnk_files_pattern? It's not used anywhere
in refpolicy along with write_lnk_files_pattern. The sesearch command shows
only the following uses of append permission for lnk_file.
# sesearch -A -c lnk_file -p append
allow files_unconfined_type file_type:lnk_file { append create execmod execute
getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto
rename setattr unlink watch write };
allow filesystem_unconfined_type filesystem_type:lnk_file { append create
execmod execute getattr ioctl link lock map mounton open quotaon read
relabelfrom relabelto rename setattr unlink watch write };
allow kern_unconfined proc_type:lnk_file { append create execmod execute
getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto
rename setattr unlink watch write };
allow kern_unconfined unlabeled_t:lnk_file { append create execmod execute
getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto
rename setattr unlink watch write };
I guess that the kern_unconfined stuff is related to the magic symlinks in /
proc/PID directories. Is there any other way where a symlink can be appended?
Does it make sense to have the append macros and the write macros with append
permission included?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: append_lnk_files_pattern
2023-09-30 11:55 append_lnk_files_pattern Russell Coker
@ 2023-10-02 12:40 ` Chris PeBenito
0 siblings, 0 replies; 2+ messages in thread
From: Chris PeBenito @ 2023-10-02 12:40 UTC (permalink / raw)
To: Russell Coker, selinux-refpolicy
On 9/30/2023 7:55 AM, Russell Coker wrote:
> Why do we have the pattern append_lnk_files_pattern? It's not used anywhere
> in refpolicy along with write_lnk_files_pattern. The sesearch command shows
> only the following uses of append permission for lnk_file.
More than likely it's simply a copy-paste when I first generated the macros.
> # sesearch -A -c lnk_file -p append
> allow files_unconfined_type file_type:lnk_file { append create execmod execute
> getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto
> rename setattr unlink watch write };
> allow filesystem_unconfined_type filesystem_type:lnk_file { append create
> execmod execute getattr ioctl link lock map mounton open quotaon read
> relabelfrom relabelto rename setattr unlink watch write };
> allow kern_unconfined proc_type:lnk_file { append create execmod execute
> getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto
> rename setattr unlink watch write };
> allow kern_unconfined unlabeled_t:lnk_file { append create execmod execute
> getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto
> rename setattr unlink watch write };
>
> I guess that the kern_unconfined stuff is related to the magic symlinks in /
> proc/PID directories. Is there any other way where a symlink can be appended?
>
> Does it make sense to have the append macros and the write macros with append
> permission included?
The way I see it (and how the various perm macros are designed), if a
rule has write, then append is also implied. Append may not make sense
for lnk_file, but I don't see a downside to having it.
--
Chris PeBenito
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-10-02 12:40 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-30 11:55 append_lnk_files_pattern Russell Coker
2023-10-02 12:40 ` append_lnk_files_pattern Chris PeBenito
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).