NetworkManager und OpenVPN vs. SELinux

Auf meinem Fedora 18 Notebook habe ich versucht, bei aktiviertem SELinux die OpenVPN-Integration des NetworkManager zu benutzen. Ging aber erstmal nicht. In /var/log/messages fand ich:

Apr  6 13:03:54 hydrogen nm-openvpn[21025]: Cannot load certificate file /home/softmetz/Dokumente/vpn/openvpn.cert.pem: error:0200100D:system library:fopen:Permission denied: error:20074002:BIO routines:FILE_CTRL:system lib: error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system lib

Außerdem bekam ich einen SElinux-Alert im System-Tray angezeigt.

SELinux is preventing /usr/sbin/openvpn from open access on the file /home/softmetz/Dokumente/vpn/openvpn.cert.pem.

*****  Plugin openvpn (47.5 confidence) suggests  ****************************

If sie openvpn.cert.pem an den Standard-Speicherort verschieben möchten, so das openvpn  open Zugriff hat.
Then sie müssen die cert-Datei ins ~/.cert-Verzeichnis verschieben
Do
# mv /home/softmetz/Dokumente/vpn/openvpn.cert.pem ~/.cert
# restorecon -R -v ~/.cert


*****  Plugin openvpn (47.5 confidence) suggests  ****************************

If sie die Kennzeichnung von openvpn.cert.pem ändern möchten, so dass openvpn open Zugriff darauf hat
Then sie müssen die Markierungen korrigieren.
Do
# semanage fcontext -a -t home_cert_t /home/softmetz/Dokumente/vpn/openvpn.cert.pem
# restorecon -R -v /home/softmetz/Dokumente/vpn/openvpn.cert.pem


*****  Plugin catchall (6.38 confidence) suggests  ***************************

If sie denken, dass es openvpn standardmässig erlaubt sein sollte, open Zugriff auf openvpn.cert.pem file zu erhalten.
Then sie sollten dies als Fehler melden.
Um diesen Zugriff zu erlauben, können Sie ein lokales Richtlinien-Modul erstellen.
Do
zugriff jetzt erlauben, indem Sie die nachfolgenden Befehle ausführen:
# grep openvpn /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:openvpn_t:s0
Target Context                unconfined_u:object_r:user_home_t:s0
Target Objects                /home/ninan/.cert/openvpn.c
                              ert.pem [ file ]
Source                        openvpn
Source Path                   /usr/sbin/openvpn
Port                          <Unknown>
Host                          hydrogen
Source RPM Packages           openvpn-2.2.2-9.fc18.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.11.1-87.fc18.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     hydrogen
Platform                      Linux hydrogen 3.8.5-201.fc18.x86_64 #1 SMP Thu
                              Mar 28 21:01:19 UTC 2013 x86_64 x86_64
Alert Count                   13
First Seen                    2013-04-06 13:03:10 CEST
Last Seen                     2013-04-10 08:48:39 CEST
Local ID                      85255eb7-cf82-47a6-b108-d086aeeaddfe

Raw Audit Messages
type=AVC msg=audit(1365576519.644:573): avc:  denied  { open } for  pid=7585 comm="openvpn" path="/home/softmetz/Dokumente/vpn/openvpn.cert.pem" dev="dm-0" ino=257061 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file


type=SYSCALL msg=audit(1365576519.644:573): arch=x86_64 syscall=open success=no exit=EACCES a0=7fff98655ed8 a1=0 a2=1b6 a3=238 items=0 ppid=7583 pid=7585 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=openvpn exe=/usr/sbin/openvpn subj=system_u:system_r:openvpn_t:s0 key=(null)

Hash: openvpn,openvpn_t,user_home_t,file,open

audit2allow

#============= openvpn_t ==============
allow openvpn_t user_home_t:file open;

audit2allow -R
require {
    type openvpn_t;
}

#============= openvpn_t ==============
userdom_mmap_user_home_content_files(openvpn_t)

Diese Fehlermeldung ist mal aussagekräftig, wenn auch sprachlich etwas holprig. Ich tat also, wie mir geheißen:

If sie openvpn.cert.pem an den Standard-Speicherort verschieben möchten, so das openvpn  open Zugriff hat.
Then sie müssen die cert-Datei ins ~/.cert-Verzeichnis verschieben
Do
# mv /home/softmetz/Dokumente/vpn/openvpn.cert.pem ~/.cert
# restorecon -R -v ~/.cert

Diesen Hinweis habe ich in weiser Voraussicht etwas abgewandelt in

# mv /home/softmetz/Dokumente/vpn/*.cert.pem ~/.cert
# restorecon -R -v ~/.cert

weil ich ja noch mehr Dateien (CA-Certs, Private-Key, Public-Key, etc) für OpenVPN brauche. Dann noch die neuen Pfade in der NetworkManager-Konfiguration angegeben, und schon geht es.

Getagged mit: , , , ,
Veröffentlicht unter Technisches Zeugs

Bericht vom Münchner Document Freedom Day 2013

Heute war Document Freedom Day. In München fand aus diesem Anlass wohl eine der gefühlt “coolsten” Aktionen dazu statt. :)

Weiterlesen ›

Getagged mit: , , ,
Veröffentlicht unter Freies Zeugs

Versammlung in München zum Document Freedom Day 2013

Document Freedom Day 2013 Banner

Am 27.03.2013 findet anlässlich des jährlichen Document Freedom Day am Sendlinger Tor eine Versammlung (ortsfest) mit Infotisch statt, wo wir (FSFE-Fellows und Freunde) über die Vorteile von offenen Formaten, Freier Software, Freie Infrastruktur und den Gefahren von Digital Restriction Management (DRM) informieren wollen.

Beginn der Versammlung ist 16h.

Bitte kommt und/oder gebt den Termin weiter. Wir freuen uns auf viele Gleichgesinnte!

Getagged mit: , , ,
Veröffentlicht unter Freies Zeugs

Fedora 18 auf Dell XPS 12

Nach einigem Warten ist endlich mein neues Notebook angekommen, ein Dell XPS 12 Ultrabook Convertible. Windows 8 flog selbstverständlich sofort runter, Fedora 18 sollte es werden.Nun schreibe ich diese Zeilen auf diesem echt schicken Gerät.

Secure Boot

Testweise lies ich Secure Boot aktiviert. Bei Bedarf, und der kommt recht schnell, lässt sich dieses aber auch via “System Settings” deaktiviern. Hierfür muss bei Erscheinen des Dell-Logos die Taste F2 solange wiederholt gedrückt werden, bis unten rechts der entsprechende Punkt etwas hervorgehoben ist.Im  Menü lässt sich dann unter “Boot” (und nicht etwa Security) das Secure Boot abschalten.

Mit F12 kommt man im Übrigen zur Auswahl des Boot-Geräts, hier musst sich den USB-Stick mit dem Fedora-Netinstall-Image auswählen, ansonsten total schmerzfrei.

Installation

Ich habe die Installation mittels Fedora 18 Netinstall (64 Bit) durchgeführt. Das Ganze ging recht reibungslos über die Bühne.

Die Verbindung mit dem WLAN funktioniert auch mit dem Installer-Kernel im 802.11n-Standard. Bei der Konfiguration des Speicher-Subsystems habe ich den Partitionstyp BTRFS ausgewählt und die Platten verschlüsselt. Diese Option legt die Blockgeräte als BTRFS-Subvolumes an. Was das im Detail bedeutet, muss ich mir noch anschauen, aber auf jeden Fall sind / (root) und /home hinterher gleich gross, teilen sich also den Speicherplatz dynamisch.

Bei der Installation mittels Netinstall werden gleich alle Updates mitinstalliert. Wenn du eine andere Variante gewählt hast, musst du erst die Updates installieren um zu sehen was ich sah. :-)

Erster Start (nach den letzten Updates) – Black Screen of Death

Nach dem ersten Reboot bekam ich nur einen schwarzen Bildschirm. Dieser Fehler ist unkritisch, lässt er sich doch mittels Kernel-Parameter acpi_backlight=vendor schnell und nachhaltig beseitigen. Dazu muss am Boot-Manager der Eintrag “Fedora” ausgewählt und mittels “e” der Eingabemodus gestartet werden. In der Zeile, die mit linuxefi beginnt, muss das ans Ende angefügt werden. Mit F10 wird dann der Kernel gebootet.

Nach dem Boot muss man diese Ergänzung ebenfalls in der Datei /etc/default/grub vornehmen, bei mir sieht die jetzt so aus:

GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-342adcbc-c1e7-4c15-9fbc-349c0b6ca586 rd.md=0 rd.lvm=0 rd.dm=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :)  rd.luks.uuid=luks-e4b8a9d6-7302-4a8f-a0c8-eae0f028216a vconsole.keymap=de rhgb quiet acpi_backlight=vendor"

Ein beherztes

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

als root schafft das Problem dann nachhaltig und für alle künftigen Kernel-Updates aus der Welt.

Das Trackpad spinnt

Nun kam der etwas antiquiert wirkende First-Boot-Wizzard.. Was auffällt ist, dass das Trackpad wie angestochen reagiert. Dies ist ein Kernel-Bug, der weiter unten behoben wird. Der Fehler mit dem Cypress-Trackpad wurde mit dem Kernel 3.8.3-201.fc18 behoben.

Zusammenfassung

Das Notebook ist richtig schön schnell und dabei hält der Akku unter KDE ca. 4h bei aktiver Nutzung mit WLAN. Das Gerät ist ordentlich verarbeitet, insbesondere der Displayrahmen wackelt nicht und man kann das Display schön dynamisch herumdrehen. Das 12″-Display zeigt Full-HD, ist dabei aber sehr gut lesbar.

Nachdem das Trackpad unter Linux ordentlich läuft (inkl. 2-Finger-Scrolling, etc), kann man sagen, dass die Hardware mit komplett freien Treibern und ohne Änderungen am System läuft (Der WLAN-Chip benutzt einen Firmware-Blob von Intel, der aber von kernel.org stammt). Auch sonst sind alle Tasten und teilweise auch Events wie das Umwandeln von Notebook in Tablet als Keycodes realisiert, lassen sich also programmieren. Sehr elegant ist die Tatsache, dass das Schließen des Deckels als Notbook ein ACPI-Close-LID-Event auslöst, während dass beim Tablet-Modus sinnvollerweise nicht passiert.

Dem Touchscreen zuliebe, der momentan offenbar nur ein Finger-Gesten (Taps) unterstützt, mache ich nun nach und nach Elemente auf dem Desktop größer. Erster Anfang war die Fensterleiste, so kann ich direkt auf das Programm fassen, welches ich sehen will.

Insgesamt ist es eine runde Sache und die Arbeit mit dem Gerät macht spaß, was auch an einer tollen Tastatur liegt.

Im Kernel 3.9 sollen dann noch viele Verbesserungen für die Hardware enthalten sein. Ich bin gespannt.

Technische Daten

[root@hydrogen ~]# lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Stepping:              9
CPU MHz:               800.000
BogoMIPS:              3591.62
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              3072K
NUMA node0 CPU(s):     0-3


[root@hydrogen ~]# lspci 
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:04.0 Signal processing controller: Intel Corporation 3rd Gen Core Processor Thermal Subsystem (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QS77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
00:1f.6 Signal processing controller: Intel Corporation 7 Series/C210 Series Chipset Family Thermal Management Controller (rev 04)
02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24)

[root@hydrogen ~]# lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 03eb:8409 Atmel Corp. 
Bus 001 Device 004: ID 0c45:646b Microdia 
Bus 001 Device 005: ID 8087:0a05 Intel Corp. 
Bus 002 Device 003: ID 8087:07da Intel Corp. 

[root@hydrogen ~]# xinput 
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ CyPS/2 Cypress Trackpad                   id=12   [slave  pointer  (2)]
⎜   ↳ Atmel Atmel maXTouch Digitizer            id=9    [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Power Button                              id=8    [slave  keyboard (3)]
    ↳ Laptop_Integrated_Webcam_1.3M             id=10   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=11   [slave  keyboard (3)]
    ↳ Dell WMI hotkeys                          id=13   [slave  keyboard (3)]




Getagged mit: , , , ,
Veröffentlicht unter Technisches Zeugs

Schluss mit dem Zentralismus, raus aus der Mainstream-Cloud

Evernote hat mich heute morgen per Mail darüber informiert, dass es wegen “Unregelmäßigkeiten” einen globalen Passwort-Reset gegeben hat.

Es ist nicht so, dass es mich überrascht oder wirklich gestört hätte (ich nutze Evernote nicht, hab da nur einen Account). Aber es hat mich zum Nachdenken gebracht. Welche Dienste nutze ich in der Cloud, wofür zahle ich sogar? Da kommen einige zusammen, insbesondere einige sehr sensible wie Kalender, Kontakte und Reader von Google, Bookmark- und Passwort-Sync-Dienste, etc.

Gleichzeitig habe ich heute gelesen, dass für Kolab 3 CardDAV und CalDAV-Support kommen wird. Damit wird die Groupware-Suite endlich wirklich interoperabel mit meinem Gerätezoo und ich werden mir in der nächsten Zeit ernsthaft Gedanken darüber machen, wie ich der Mainstream-Cloud entkommen kann.

Wohlgemerkt rede ich hier nur über Dienste, die meine Daten unsichtbar für euch verwalten. Bei den Social Networks denke ich schon länger über zwei Alternativen nach.

Eine Variante wäre der maximale Reichweiten-Ausbau, indem ich alle Social Networks miteinander kopple und dann aus dieser WordPress-Instanz befülle. Vorteil wäre es, dass man mir auf allen Kanälen mühelos folgen kann, aber wie gehe ich mit Feedback um?

Andererseits könnte ich mich auch komplett auf meinen eigenen Server zurückziehen. Blog als Journal und Wiki als Knowledge-Base, brauchts wirklich mehr für das digitale Alter Ego? Zum Austausch zu Fachthemen wäre ich natürlich immer noch auf Mailinglisten, Foren oder in Wikis unterwegs. So wie ich jeden Tag arbeiten oder zu irgendwelchen Treffen gehe. Nur mein Zuhause wäre dann an einem Ort, wer was von mir will klopft an und bekommt immer Kaffee und Kuchen. :) Diese Variante gefällt mir sehr gut, aber kommt ihr hierher?

Wie macht ihr das? Wo seht ihr Probleme? Werdet ihr mich auf Netzwerk XYZ vermissen?

Getagged mit: , ,
Veröffentlicht unter Soziales Zeugs
Neueste Dents
Meet me here
Alte Posts
QR Code