From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Tue, 19 Aug 2014 09:08:26 -0400 Subject: [refpolicy] Restricting access to pcscd socket In-Reply-To: <20140215220025.2cb38402@gentp.lnet> References: <1392407241-18492-1-git-send-email-aranea@aixah.de> <52FFCFC0.8030407@tresys.com> <20140215220025.2cb38402@gentp.lnet> Message-ID: <53F34C4A.4050307@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 2/15/2014 4:00 PM, Luis Ressel wrote: > On Sat, 15 Feb 2014 15:36:16 -0500 > "Christopher J. PeBenito" wrote: > >> Typically I would take something like this. Conditionally making the >> policy stricter is usually a good thing. I'm not so sure that it >> makes sense here. It doesn't seem like it buys much. > > I'm not sure about either. If I understand it correctly, once one > application accesses a smartcard, it gets exclusive access - other > applications can't access it anymore until the using application stops > using the smartcard (and hopefully resets it before). > > On the other hand, something as security-critical as a smartcard daemon > should be well-protected, and mozilla_plugin_t is a really exposed > domain. Same goes for xguest_t - you expect that one to have minimal > permissions, and that normally wouldn't include access to smartcards. > > Therefore, I think it would be a good idea to add these booleans. Could > you perhaps elaborate a bit on them "not buying much"? The ability to check passwords suffers the same problem but we don't make the chkpwd rules conditional. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com