RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1877522 - [RFE] scap-workbench with sudo option for remote systems
Summary: [RFE] scap-workbench with sudo option for remote systems
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: scap-workbench
Version: 8.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 8.0
Assignee: Matěj Týč
QA Contact: Matus Marhefka
Mirek Jahoda
URL:
Whiteboard:
: 1751818 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-09 18:55 UTC by Olimp Bockowski
Modified: 2024-10-01 16:51 UTC (History)
7 users (show)

Fixed In Version: scap-workbench-1.2.0-8.el8
Doc Type: Enhancement
Doc Text:
.`scap-workbench` can now scan remote systems using `sudo` privileges The `scap-workbench` GUI tool now supports scanning remote systems using passwordless `sudo` access. This feature reduces the security risk imposed by supplying root's credentials. Be cautious when using `scap-workbench` with passwordless `sudo` access and the `remediate` option. Red Hat recommends dedicating a well-secured user account just for the OpenSCAP scanner.
Clone Of:
Environment:
Last Closed: 2021-05-18 16:14:55 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Scan of remote system using sudo user with password (137.20 KB, image/png)
2021-02-02 16:27 UTC, Matus Marhefka
no flags Details
Scan of remote system using sudo user without password (148.31 KB, image/png)
2021-02-02 16:27 UTC, Matus Marhefka
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2021:1936 0 None None None 2021-05-18 16:14:57 UTC

Description Olimp Bockowski 2020-09-09 18:55:17 UTC
Description of problem:

Using CLI on remote systems we use oscap-ssh (from openscap-utils package) and what is crucial here is the fact it has --sudo options. 
The same is needed for scap-workbench, but it has nothing like that when launching or in GUI Window. 


Version-Release number of selected component (if applicable):
<= 1.2.1

How reproducible:
always, lack of feature

Steps to Reproduce:
run on remote session using non-root user

Actual results:
some reports are different than running as root (or having SUID on oscap on remote system)


Expected results:
we can use sudo that is possible for a remote user

Additional info:

It is reported for upstream:
[RFE] Add ability to run system scan / system remediation under sudo
https://github.com/OpenSCAP/scap-workbench/issues/46

Comment 4 Matěj Týč 2020-10-06 10:10:49 UTC
Hello Olimp,
the primary purpose of scap-workbench is to be a SCAP tailoring editor that can, among other things, scan. Although it may be tempting to use it as a user-friendly scanner, that's not really the intention. The command-line tool is a preferred way how to scan systems as it is much more suitable for automation, which is a key factor when considering security compliance.

The linked customer case doesn't get into details of why they want to use the workbench - it may be that they just need to alter their workflow.

Comment 7 Matěj Týč 2020-12-01 17:55:32 UTC
It is technically possible to introduce support for scanning of systems using accounts that can run an oscap scan on the remote systems without having to specify a password.

Comment 8 Matěj Týč 2020-12-01 18:03:52 UTC
In other words, it is possible to support users that can do passwordless sudo.

I would also like to make sure that you are aware of the "Dry run" mode of scap-workbench - that one supplies you with the full command-line that you can copy-paste into a terminal to conduct a scan that you define using the GUI.

Comment 11 Matus Marhefka 2021-02-02 16:27:11 UTC
Created attachment 1754426 [details]
Scan of remote system using sudo user with password

Comment 12 Matus Marhefka 2021-02-02 16:27:58 UTC
Created attachment 1754435 [details]
Scan of remote system using sudo user without password

Comment 23 Matěj Týč 2021-03-12 17:09:18 UTC
*** Bug 1751818 has been marked as a duplicate of this bug. ***

Comment 25 errata-xmlrpc 2021-05-18 16:14:55 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (scap-workbench bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1936


Note You need to log in before you can comment on or make changes to this bug.