Closed stephensmalley closed 8 years ago
same here:
[root@void kcinimod]# seinfo -asubj.subj_type_attribute
Type Attributes: 1
subj.subj_type_attribute
[root@void kcinimod]# sesearch -A -s subj.subj_type_attribute
[root@void kcinimod]# echo $?
0
I'll confirm that is a behavior that was missed.
Please confirm this has the behavior you expect (I don't think I ever used it before on setools3).
Interestingly, yields more results than setools3 on the same query and policy. Not sure what the difference is yet, as I can't just sort and the diff the results due to different formatting. Also, neither one is truly what I want - I just want allow rules written on that attribute (e.g. sesearch -A -s domain returning 'allow domain' rules), not rules written on allow domain or any type to which it expands.
Ok, I misunderstood your original request. In the absence of switches mentioned below, sesearch does indirect matching of source/target/default (expand attributes). If you're looking for sesearch -A -s domain
to return rules with domain
as the subject, then you want to add the -ds
switch (directly match source; there is also a -dt
switch). This is one of the few CLI changes in setools4.
Prior to the patch, if the criteria matching was indirect, the source/target of the rule would be expanded and the rule would match if the criterion is in that set. Post the patch, both the rule source/target AND the criterion are expanded and the rule matches if there is an intersection between the two sets. In other words, sesearch -A -s domain
means all allow rules with a subject of one of the types in domain, and sesearch -A -s domain -ds
means all allow rules with the domain attribute as the subject.
Does not work with DSSP [1]. sesearch maxes out CPU and does not return on a attribute query. Everything else has the same behavior as before (except the GUI improvements).
If subj.subj_type_attribute
is equivalent to the domain
attribute in other policies, then you're asking for nearly all rules (i.e. only skipping stuff like filesystem associate rules).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 03/16/2016 02:11 PM, Chris PeBenito wrote:
If
subj.subj_type_attribute
is equivalent to thedomain
attribute in other policies, then you're asking for nearly all rules (i.e. only skipping stuff like filesystem associate rules).
K. let me try some smaller attribute then..
--- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/TresysTechnology/setools/issues/111#issuecomment-19 7319911
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQGcBAEBCAAGBQJW6VvjAAoJECV0jlU3+UdpRT0L/i0Es8f691dYBeZkN/Gpv4gQ 08ZRkJdKDdvBSMkRuZVZixpxHRYh1rhxRXqMzD4U5MSo7bReo2OdZJu2VWJZOfCh 0qnmXnbwBWVhojjStxa7egmzemNHJamdBga93rejluQIfXssrk0iHKrodv0+14EO ck6njJMSWvedySU7sbU0TZ2DZBpIQbl+U0oCUafNim/ppnMYPOElNBJTIFsJaxzG cXzjyqJQNfvz1zFHl88sUKwKPTGF47VQ/sDL+pF0smUQt6IcSrjVMUaklI5uxZO/ eYQyAGapf5VtRCE+fyau79pfqoPREQtrCx6qFUUJMbgStPkWVE0CDo2a4zx9I94F kONiNLxidiAClRP4684WOBVjrWyI5Bq+zJCKizBrFqr8orKyQxfP9gttg23+Kdbv XYvUiz3jHmog0zKSdn/4/s1Ixx7dSk8N1LeaHXApYOT1CDHbksRM9l5KIGpaKF8l DUtWOI51nIvwtlmNNwviZGAMH7VfJ8WgS74uga8cqg== =UO2V -----END PGP SIGNATURE-----
Okay yes , you're right. I tried a smaller attribute and that works
Prior to the patch, I got no results from sesearch on attributes. After the patch, I get results, including both direct and indirect, although I do get more results than with setools3. With the -ds option, I get only the direct matches as you said.
The -ds
option should have worked too, before the patch (that code path wasn't modified by the patch) and there are unit tests for that.
I did a comparison between setools3 and setools4 post patch. I did a test using the cron_job_domain
attribute which consists of cronjob_t
and unconfined_cronjob_t
on the policy I used.
sesearch -A -s cron_job_domain
returned all rules that have cronjob_t
and unconfined_cronjob_t
as the subject, but not rules with cron_job_domain
as the subject.sesearch -A -s cron_job_domain
essentially returned the union of results of sesearch -A -s cronjob_t
and sesearch -A -s unconfined_cronjob_t
, which includes cron_job_domain
rules and other attribute rules such as allow domain [...]
.Re-tested setools4 before the patch and confirmed that -ds option worked there. So it was only broken without the -ds option. Sounds like setool4 after the patch has correct behavior and that setools3 was omitting relevant results. So I think this issue is resolved, thanks.
With setools4, I get no results when trying to search by attribute, e.g. sesearch -A -s domain sesearch -A -t base_file_type
This is using upstream selinux userspace, i.e. libsepol 2.5, FWIW.