Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) upozorňuje na sérii kritických zranitelností v Cisco Adaptive Security Appliance (ASA) a Firepower Threat Defense (FTD) a Cisco IOS, CVE-2025-20333, CVE-2025-20363 a CVE-2025-20362. Zneužití těchto zranitelností může umožnit vzdálenému neautentizovanému útočníkovi spustit libovolný kód (RCE). Společnost Cisco uvedla, že si je vědoma aktivního zneužívání těchto zranitelností.
Ochrana uživatelů a zároveň příznivé podmínky pro rozvoj umělé inteligence (AI). Ministerstvo průmyslu a obchodu (MPO) připravilo minimalistický návrh implementace evropského nařízení o umělé inteligenci, tzv. AI aktu. Český zákon zajišťuje ochranu občanům a bezpečné používání AI, ale zároveň vytváří pro-inovační prostředí, ve kterém se může AI naplno rozvíjet, firmy mohou využít jeho potenciál a nebudou zatíženy zbytečnou administrativou. Návrh je nyní v meziresortním připomínkovém řízení.
Dle plánu Linus Torvalds odstranil souborový systém bcachefs z mainline Linuxu. Tvůrce bcachefs Kent Overstreet na Patreonu informuje, že bcachefs je nově distribuován jako DKMS modul.
PIF, Silver Lake a Affinity Partners kupují videoherní společnost Electronic Arts (EA) za 55 miliard dolarů (1,14 bilionu korun).
Konference LinuxDays 2025 proběhne již tento víkend 4. a 5. října v Praze v areálu ČVUT v Dejvicích na FIT. Konference znamená desítky přednášek a workshopů, zástup zajímavých osobností, místo pro setkání, spoustu nových nápadů a informací a stánky řady různých projektů: Fedora, openSUSE, vpsFree.cz, Mozilla, MacGyver - bastlíři SH, OpenAlt a mnoho dalších. Účast na konferenci je zdarma.
Před měsícem Google oznámil, že bude vyžadovat ověření identity vývojářů aplikací pro Android. Dnes se k této změně vyjádřil F-Droid, tj. instalovatelný katalog svobodných a open source aplikací pro platformu Android. Změna ohrožuje F-Droid a další otevřené platformy pro distribuci aplikací.
Po 9 týdnech vývoje od vydání Linuxu 6.16 oznámil Linus Torvalds vydání Linuxu 6.17. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies.
The Catch 2025, oblíbená podzimní CTF (Capture the Flag) soutěž, začne v pondělí 6. října přesně ve 12:00. Letošní ročník s podtitulem TCC Power Grid prověří znalosti hráček a hráčů na scénářích spojených s elektrickou rozvodnou sítí. Kromě hlavních výher čekají na soutěžící ceny až do 50. místa a také speciální bonusy za nejrychlejší řešení či kvalitní write-upy.
Společnost System76 vydala beta verzi Pop!_OS 24.04 LTS s novým desktopovým prostředím COSMIC. Videoukázky na YouTube.
Komunitní Wikikonference 2025 aneb setkání s tvůrci české Wikipedie plné přednášek, diskuzí a novinek ze světa Wikimedia, proběhne v sobotu 8. listopadu 2025 v Didaktikonu Kampusu Hybernská v Praze. Hlavním tématem letošního setkání je otázka, která hýbe nejen komunitou, ale i širší společností: „Je Wikipedie jenom pro boomery?“
For quiet a long time POSIX systems have got along with so called discretionary access control (DAC). It means that system trusts its applications they work as intended. If e.g. ls has the privilege to read the content of some directory, it is OK to let it read. But if someone attacker changed ls binary in a way the new application will read sensitive data and send it silently to attacker's server. The answer is to confine the application by fence of minimal access privileges they need to serve their purpose. Obviously ls has no reason to open socket connections on network layer (in any way). This principal is called mandatory access control (MAC).
SELinux is just one among many implementations of LSM (Linux Security Model) kernel framework, that brings complex MAC to Linux. The other members of LSM family are Tomoyo, AppArmor, Yama or Smack. Moreover SELinux implements FLASK (Flux Advanced Security Kernel) architecture which is more general concept describing model for flexible and dynamic type of enforcement mechanisms. FLASK architecture has its roots in 1980s and one of research projects that gave life to FLASK was designed for microkernel based operating systems. The microkernel design is well reflected even in SELinux architecture itself.
SELinux components spans over kernel space as well as user space. The kernel part consists of three strictly separated components where each one of them is responsible for its own part of a work and should be easily replaceable. This is sort of leftover from microkernel FLASK design. The core component is SELinux security server. This part is responsible for policy decisions. The second component, the AVC (access vector cache) is, and being obvious, cache that quickly responds previously returned policy decisions by security server during cache miss. The final part is a bundle of kernel object managers, that ensures type enforcement itself. Kernel object managers guarantee that any access request to its resources are properly translated into access vector queries to security server. So usual workflow looks like: You want to access inode? It's a kernel object, so kernel object manager has to query AVC for an answer. If AVC miss then it'll ask security server for an access vector decision. This decision is then stored into AVC.
For the purpose this artcle, it's enough to state that user space part of SELinux is libselinux library. What is more important: user space part of SELinux (among other things) provides interface that helps to create user space object managers. These managers are used to maintain user space objects. OK, but what are the user space objects at all? Kernel space objects are clear: inodes, files, devices, sockets etc. But why should one bother to maintain some user space objects? Consider database management system. You want to limit users to use only certain resources of dbms. You can define various objects e.g.: tables, views, triggers, db links, etc. Then, you are able to label these objects accordingly to confine db users into more clearly defined area. Libselinux has its own AVC that caches decisions for user space managed objects. But the policy decisions and SELinux types/domains are still managed by security server!
Let's look at simple example of how the type enforcement works in kernel. What will happen when process requests opening some file (access inode)? Quick search through Linux sources reveals that apart from security functions there's only one place where an inode permissions are checked. It's the fs/namei.c source file.
int __inode_permission(struct inode *inode, int mask)
{
int retval;
if (unlikely(mask & MAY_WRITE)) {
/*
* Nobody gets write access to an immutable file.
*/
if (IS_IMMUTABLE(inode))
return -EACCES;
}
/* DAC access control */
retval = do_inode_permission(inode, mask);
if (retval)
return retval;
/* cgroup checks for devices only */
retval = devcgroup_inode_permission(inode, mask);
if (retval)
return retval;
/* LSM security checks */
return security_inode_permission(inode, mask);
}
As you can see, the process of deciding whether the user has access permissions for inode or has not actually proceeds in three steps. First the classical DAC rights are checked, then cgroups (Control Groups) permissions. Cgroup permissions check takes effect only on inodes regarding block or character devices. The final check is the LSM check itself. In general that means you have to pass all three security checks to gain the access.
Access revocation is unending story about how to revoke access to resources after the permission settings are changed in a sane way. Process 'A' has access permission to some file 'F'. The process has opened the file and now it can write the file through open fd. But even if you change the access rights to the file's inode you won't interrupt the process 'A' from writing the file through open fd. Only each future call to open syscall will fail. What SELinux offers is actually 'sort of' revocation by changing the object's type. In our case you can change inode's type and during the next write syscall, SELinux will fail the write call. It shouldn't be expensive as after first query the AVC will store the access decision and every following write call will receive the answer from AVC. Actually, SELinux hook function can detect if security context of inode has changed since the file has been opened. LSM support this feature by security_file_permission hook and it's up to security module if it implements it or not. Did you know that?:)
If you glimpse shortly into linux/security.h header file you'll find out there are hook functions for most of the system calls. But especially one syscall, the ioctl is a bit different. Ioctl syscall represents kernel configuration interface used to interchange data between user space and kernel space. In the beginning it's been used as configuration interface for tty devices solely, but later it's become general configuration interface. Nowadays, there are dozens of different ioctl calls in the kernel. List of devices that are configured by ioctl syscall is quite a long one: all *-ROM mechanics, SCSI devices, device-mapper virtual devices, loop devices, etc. What is a real challenge with the ioctl syscall is the fact, that ioctl is actually a syscall to implement new syscall within the kernel. Why so? The ioctl syscall prototype is:
int ioctl(int fd, unsigned long commmand, ...);
commmand parameter is an ioctl identifier number. The id contains information about command type and its direction (write data to kernel, read data into user space). The third variable parameter can be of any type or null. There are two major arguments why security people don't like the ioctl syscall. The first reason is, that ioctl handler (usually a device driver) has to be very careful about the third parameter passed from user space. The user memory has to be copied into kernel memory space and you need to check if every string is correctly terminated. Fail to do and you risk that user try to do some ugly things with the memory beyond the unterminated string. The second argument is simple. If you consider the abundant quantity of different ioctl implementations you will simply realise that its nearly impossible to verify every ioctl. The security maintainer would have to check every ioctl implementation and also he would have to completely understand what is driver trying to do during the ioctl handling. For example: you can have driver that receives read only ioctl parameter. That means the driver will fill user provided area with some data from kernel. It's supposed to supply some statistic data about device usage. But the driver author may have decided to do some potentially harmful operation during ioctl handling (for example reset the statistic data to initial value). Do you want that operation to be accessed by general user? Or rather, do you want only some privileged user to do that operation. And who should decide that? In any way, this decision should not be made be SELinux maintainers but by the person responsible for the device driver. And I don't even mention that some drivers are at least partially rewritten from time to time. So if you look into SELinux implementation of security_file_ioctl hook you'll find out that there are only a few ioctl commands that SELinux cares about:
static int selinux_file_ioctl(struct file *file, unsigned int cmd,
unsigned long arg) {
/* ... */
switch (cmd) {
case FIONREAD:
/* fall through */
case FIBMAP:
/* fall through */
case FIGETBSZ:
/* fall through */
case FS_IOC_GETFLAGS:
/* fall through */
case FS_IOC_GETVERSION:
error = file_has_perm(cred, file, FILE__GETATTR);
break;
case FS_IOC_SETFLAGS:
/* fall through */
case FS_IOC_SETVERSION:
error = file_has_perm(cred, file, FILE__SETATTR);
break;
/* sys_ioctl() checks */
case FIONBIO:
/* fall through */
case FIOASYNC:
error = file_has_perm(cred, file, 0);
break;
case KDSKBENT:
case KDSKBSENT:
error = cred_has_capability(cred, CAP_SYS_TTY_CONFIG,
SECURITY_CAP_AUDIT);
break;
/* default case assumes that the command will go
* to the file's ioctl() function.
*/
default:
error = file_has_perm(cred, file, FILE__IOCTL);
}
return error;
}
As you can see only a few ioctl commands are somehow translated into more specific SELinux permission checks like FILE__GETATTR or FILE__SETATTR. The default behaviour is to check only general FILE__IOCTL permission or in other words: SELinux verifies if current process is in proper domain to do ioctl on open file. The short answer on question why SELinux doesn't care about the specific ioctl commands is that only the driver's author (should :)) knows about the driver's internals.
I hope you find at least some parts of the blog entry interesting and feel free to discuss any misleading info or clear mistakes. Thanks you for reading
Tiskni
Sdílej:
Jestli máte někoho kvalitativně srovnatelného v zásobě, tak si rád přečtu.James Joyce. Četl jsem od něj jen sbírku povídek Dubliners, ale stála za to.
ls
je dobrý v tom, že je jednoduchý a jasný. Na druhou stranu je to ale utilita a spouští se obvykle z shellu nebo jiné čistě uživatelské aplikace. Tudíž běží obvykle s právy uživatele
a navíc alespoň ve Fedoře nemá nastavený žádný speciální typ.
$ ls -Z /bin/ls -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /bin/lsTakže z praktického hlediska postrádá smysl a lepší by bylo jako příklad použít něco, co se opravdu SELinuxem už dneska v praxi zabezpečuje nebo to alespoň dává nějaký konkrétní smysl. Snad to pomůže.
Jinak taky budu potřebovat omezit FTP pro jednoho kolegu, ale to zatím nespěchá (FTP pojede, až dodá disk) a předpokládám že konfigurák někde najdu.Kdybys na to chtěl přeci jen zkusit selinux, tak se obejdeš bez vlastních politik, stačí ti to jenom nastavit
podle ftpd_selinux (8)
(a na fedoře ještě předtím doinstalovat policycoreutils-python
, v kterých je semanage
).