-
Notifications
You must be signed in to change notification settings - Fork 141
/
usbguard-daemon.conf.in
215 lines (197 loc) · 6.52 KB
/
usbguard-daemon.conf.in
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
#
# Rule set file path.
#
# The USBGuard daemon will use this file to load the policy
# rule set from it and to write new rules received via the
# IPC interface.
#
# RuleFile=/path/to/rules.conf
#
RuleFile=%sysconfdir%/usbguard/rules.conf
#
# Rule set folder path.
#
# The USBGuard daemon will use this folder to load the policy
# rule set from it and to write new rules received via the
# IPC interface. Usually, we set the option to
# /etc/usbguard/rules.d/. The USBGuard daemon is supposed to
# behave like any other standard Linux daemon therefore it
# loads rule files in alpha-numeric order. File names inside
# RuleFolder directory should start with a two-digit number
# prefix indicating the position, in which the rules are
# scanned by the daemon.
#
# RuleFolder=/path/to/rulesfolder/
#
RuleFolder=%sysconfdir%/usbguard/rules.d/
#
# Implicit policy target.
#
# How to treat devices that don't match any rule in the
# policy. One of:
#
# * allow - authorize the device
# * block - block the device
# * reject - remove the device
#
ImplicitPolicyTarget=block
#
# Present device policy.
#
# How to treat devices that are already connected when the
# daemon starts. One of:
#
# * allow - authorize every present device
# * block - deauthorize every present device
# * reject - remove every present device
# * keep - just sync the internal state and leave it
# * apply-policy - evaluate the ruleset for every present
# device
#
PresentDevicePolicy=apply-policy
#
# Present controller policy.
#
# How to treat USB controllers that are already connected
# when the daemon starts. One of:
#
# * allow - authorize every present device
# * block - deauthorize every present device
# * reject - remove every present device
# * keep - just sync the internal state and leave it
# * apply-policy - evaluate the ruleset for every present
# device
#
PresentControllerPolicy=keep
#
# Inserted device policy.
#
# How to treat USB devices that are already connected
# *after* the daemon starts. One of:
#
# * block - deauthorize every present device
# * reject - remove every present device
# * apply-policy - evaluate the ruleset for every present
# device
#
InsertedDevicePolicy=apply-policy
#
# Control which devices are authorized by default.
#
# The USBGuard daemon modifies some the default authorization state attributes
# of controller devices. This setting, enables you to define what value the
# default authorization is set to.
#
# * keep - do not change the authorization state
# * none - every new device starts out deauthorized
# * all - every new device starts out authorized
# * internal - internal devices start out authorized, external devices start
# out deauthorized (this requires the ACPI tables to properly
# label internal devices, and kernel support)
#
AuthorizedDefault=none
#
# Restore controller device state.
#
# The USBGuard daemon modifies some attributes of controller
# devices like the default authorization state of new child device
# instances. Using this setting, you can control whether the
# daemon will try to restore the attribute values to the state
# before modification on shutdown.
#
# SECURITY CONSIDERATIONS: If set to true, the USB authorization
# policy could be bypassed by performing some sort of attack on the
# daemon (via a local exploit or via a USB device) to make it shutdown
# and restore to the operating-system default state (known to be permissive).
#
RestoreControllerDeviceState=false
#
# Device manager backend
#
# Which device manager backend implementation to use. One of:
#
# * uevent - Netlink based implementation which uses sysfs to scan for present
# devices and an uevent netlink socket for receiving USB device
# related events.
# * umockdev - umockdev based device manager capable of simulating devices based
# on umockdev-record files. Useful for testing.
#
DeviceManagerBackend=uevent
#!!! WARNING: It's good practice to set at least one of the !!!
#!!! two options below. If none of them are set, !!!
#!!! the daemon will accept IPC connections from !!!
#!!! anyone, thus allowing anyone to modify the !!!
#!!! rule set and (de)authorize USB devices. !!!
#
# Users allowed to use the IPC interface.
#
# A space delimited list of usernames that the daemon will
# accept IPC connections from.
#
# IPCAllowedUsers=username1 username2 ...
#
IPCAllowedUsers=root
#
# Groups allowed to use the IPC interface.
#
# A space delimited list of groupnames that the daemon will
# accept IPC connections from.
#
# IPCAllowedGroups=groupname1 groupname2 ...
#
IPCAllowedGroups=
#
# IPC access control definition files path.
#
# The files at this location will be interpreted by the USBGuard
# daemon as access control definition files for the IPC interface.
# The (base)name of a file should be in the form:
#
# [user][:<group>]
#
# where user is either username or UID and group is either groupname or GID.
# IPC access control files should contain lines in the form:
#
# <section>=[privilege1][,privilege2] ...
#
# This way each file defines who is able to connect to the IPC
# bus and what privileges he has. Note that the IPC access control
# files need to have file permissions set to 0600.
#
IPCAccessControlFiles=%sysconfdir%/usbguard/IPCAccessControl.d/
#
# Generate device specific rules including the "via-port"
# attribute.
#
# This option modifies the behavior of the allowDevice
# action. When instructed to generate a permanent rule,
# the action can generate a port specific rule. Because
# some systems have unstable port numbering, the generated
# rule might not match the device after rebooting the system.
#
# If set to false, the generated rule will still contain
# the "parent-hash" attribute which also defines an association
# to the parent device. See usbguard-rules.conf(5) for more
# details.
#
DeviceRulesWithPort=false
#
# USBGuard Audit events log backend
#
# One of:
#
# * FileAudit - Log audit events into a file specified by
# AuditFilePath setting (see below)
# * LinuxAudit - Log audit events using the Linux Audit
# subsystem (using audit_log_user_message)
#
AuditBackend=FileAudit
#
# USBGuard audit events log file path.
#
AuditFilePath=%localstatedir%/log/usbguard/usbguard-audit.log
#
# Hides personally identifiable information such as device serial numbers and
# hashes of descriptors (which include the serial number) from audit entries.
#
HidePII=false