Re: RFC: Remove write permissions from executables
On Friday 22 January 2010 10:25:47 am David Malcolm wrote: > i.e. it seems to me like it's worth going through the Feature process > (either as a Feature or an Enhancement), if only to capture the standard > concerns there and create a URL describing the change; see: > https://fedoraproject.org/wiki/Features > > Bear in mind that the deadline for requesting F13 features is in 4 days > time (if memory serves) > > How many files would be affected by the change? We would want to change the owner write permission bit for all executables. In F-12 we took care of the major directories, this is phase 2 of the same project where we take a bigger step. Phase 1 was proving that the missing write permission on directories won't mess up system updates. Phase 2 would do the same to files. > All executables on the system? Yep. > Would any of the language runtimes be broken by this change > (e.g. for shebang scripts?) Nope. You can change them all on your system right now if you want. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Remove write permissions from executables
On Friday 22 January 2010 01:30:11 pm Richard Zidlicky wrote: > > We would want to change the owner write permission bit for all > > executables. In F-12 we took care of the major directories, this is > > phase 2 of the same project where we take a bigger step. Phase 1 was > > proving that the missing write permission on directories won't mess up > > system updates. Phase 2 would do the same to files. > > so one of the next steps might also be to allow some filesystems to be > read-only? Can be done manually of course but most of the time I am too > lazy to do that. That makes "yum update" and friends messy. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Remove write permissions from executables
On Friday 22 January 2010 09:54:35 pm Garrett Holmstrom wrote: > > I don't expect any problems from this change (it can affect only daemons > > that drop capabilities, and executables owned by other users than root); > > in the unusual case where making the executeable not writeable did case > > some problems, the packager could override the change by explicitly > > specifying the required permissions using %attr in the %files section of > > the spec file. > > > > What do you think? > > I presume this isn't going to break prelink? prelink as run from cron has CAP_DAC_OVERRIDE, so it will not be broken. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gvfs causes hangs
Hello,
I have been running into something on F-12 that is really annoying and was
wondering if anyone else is seeing this. When I use kmail and want to attach a
file that is not in my Documents folder and go up one level to my homedir, it
hangs. I can't do anything with kmail except kill the email I was composing.
Digging into this further, if you run lsof, it hangs when it gets to ~/.gvfs:
alarm(15) = 0
write(5, "\240(A\0\0\0\0\0", 8) = 8
write(5, "\23\0\0\0", 4)= 4
write(5, "/home/sgrubb/.gvfs\0", 19)= 19
write(5, "\0\20\0\0", 4)= 4
read(6, 0x7fff9cc98428, 4) = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
alarm(0)= 0
rt_sigaction(SIGALRM, {SIG_DFL, [ALRM], SA_RESTORER|SA_RESTART,
0x7ff0359ac740}, {0x412140, [ALRM], SA_RESTORER|SA_RESTART, 0x7ff0359ac740}, 8)
= 0
close(5)= 0
close(6)= 0
rt_sigaction(SIGALRM, {0x412140, [ALRM], SA_RESTORER|SA_RESTART,
0x7ff0359ac740}, {SIG_DFL, [ALRM], SA_RESTORER|SA_RESTART, 0x7ff0359ac740}, 8)
=
0
alarm(5)= 0
wait4(-1,
And also find ~ -name anything also hangs:
open("..", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = 5
fstat(5, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
fchdir(5) = 0
close(5)= 0
newfstatat(AT_FDCWD, ".gvfs",
Is this a defective file system or are a whole bunch of apps needing to be
fixed? Also, do other people notice the same thing?
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gvfs causes hangs
On Saturday 23 January 2010 08:53:08 am Mamoru Tasaka wrote: > > Is this a defective file system or are a whole bunch of apps needing to > > be fixed? Also, do other people notice the same thing? > > Perhaps this issue: > https://fedoraproject.org/wiki/Common_F12_bugs#FUSE_mounts_may_hang > https://bugzilla.redhat.com/show_bug.cgi?id=493565 Probably. This really ought to be fixed. If you are in bash and type "file .gv" and then hit tab, your shell is hung. Running "ls -a ~" also hangs. Basically any app that stats files in your home dir will hang. Shouldn't a bug this bad have prevented F-12 from being released? This should have been a blocker. When I use firefox to attempt to add an attachment to bugzilla and have to go into my homedir, firefox hangs. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Monday, August 08, 2011 12:23:43 PM Adam Jackson wrote:
> * 2: how do we go about doing it?
> All of this is only an issue because most build systems don't let you
> say different CFLAGS or LDFLAGS for shared libraries and executables.
> Sigh.
>
> So instead, we'll teach gcc to figure it out. To do this we'll use the
> -specs flag to pass some rewrite rules to the compiler driver. At
> compile time, if we don't see -fPIC or -fPIE on the command line, we'll
> add -fPIC. At link time, if we don't see -shared, we'll add -pie. This
> way we build relocatable objects that are always suitable for either
> type of final link object, and we'll only attempt to build a PIE if we
> know we're not building a shared library. Victory!
This is not the policy that I asked for. When you make a PIE executable, you
get ASLR which is good. But the way it does that is making a weakness in the
executable for the relocations. It causes a new segment to be writable. So,
you need full relro support when you do PIE to cover that new weakness. But
full relro can be expensive, so we only want that if the PLT is small.
(Defining small is still TBD.)
What we want is this:
1) Everything is compiled with partial relro. Libraries, executables, daemons,
setuid/setgid/setcap apps.
2) Anything that is setgid/setuid/setcap/daemon also include the "now" flags
and is PIE.
3) Anything that is parsing data from untrusted sources should also have full
relro/pie. That would be things like tcpdump/wireshark/firefox/evince
/file/netpbm etc.
4) Anything that has pie, should should also have full relro, therefore we
need to double check anything with PIE to make sure its really a good idea.
I sent an email to the fedora-test list last week announcing a program that
can check any package or the whole distribution for compliance with this
policy with the exception of rule #3 above. No idea how to make a heuristic
for that. The program is located here:
http://people.redhat.com/sgrubb/files/rpm-chksec
> * 3: what does this mean for you?
>
> The link-time bit of the last paragraph required a bit of gcc magic to
> get right (previously specs rules could only add strings to the command
> line of the program to invoke; they could not rewrite gcc's notion of
> which flags had been passed in the first place). Thanks to a patch from
> Jakub Jelinek, this is now fixed in gcc-4.6.1-7.fc16, and will be in gcc
> 4.7 and later. As a result, %defined _hardened_build 1 will not work
> until that gcc update has gone through.
>
> Once that's done (and redhat-rpm-config-9.1.0-15.fc16 has been gone
> through updates), if you're using a %configure-style spec file, defining
> the magic macro is all you have to do. The rpm macros will notice the
> macro, and put the right magic into CFLAGS and LDFLAGS, and everything
> is great and wonderful.
Except that is not exactly the policy I asked for. :)
> If you're _not_ using %configure, then you have to do whatever is
> conventional for your build system to get CFLAGS and LDFLAGS inherited
> properly. For CFLAGS, this will be $RPM_OPT_FLAGS or %{optflags} as
> before. As of rpm-4.9.1-3.fc16, you will be able to say $RPM_LD_FLAGS
> for the corresponding LDFLAGS values. Until then, there is no such
> shell variable, but you can get the same effect from
> %{?__global_ldflags}. Yes, that's ugly, sorry.
>
> If you are the owner of one of the packages listed here:
>
> https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_fl
> ags
This list is woefully incomplete. I would advocate a much larger list. For
example, sudo is a very important program that we make security claims about.
It is not on that list.
> Then I have locally built (though not extensively tested) your package
> with the appropriate specfile modifications, and the results do indeed
> appear to be fully hardened. If you would like to handle the rebuilds
> yourself, please let me know. Otherwise I will submit them myself once
> the relevant updates have gone through.
I anyone does this and the program is used extensively, we need to know the
extent of the performance hit. If this flag automatically turns on full relro
for libraries, we have a problem.
I think there should have been some discussion about this on the FESCO request
I submitted. I have some concerns about what was implemented. Are there bz
filed for this or more discussion about it somewhere?
Thanks,
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tuesday, August 09, 2011 07:51:07 AM Matthew Garrett wrote: > On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote: > > This list is woefully incomplete. I would advocate a much larger list. > > For example, sudo is a very important program that we make security > > claims about. It is not on that list. > > Because it's SUID. ? Its one in the target group. > > I think there should have been some discussion about this on the FESCO > > request I submitted. I have some concerns about what was implemented. > > Are there bz filed for this or more discussion about it somewhere? > > We spent weeks discussing this. Where were you during the meetings? Taking RHEL6 through common criteria and FIPS-140, filing dozens of security bugs after studying some problems and sending patches. I am monitoring the FESCO ticket, but I don't monitor fedora-devel all the time because there are way too many arguments for my taste. Regardless, should there not have been some hint about anything on the ticket? I responded to any review request for the wiki page and such. My main concern is that the macro will be misapplied and overall performance will take a hit. I don't know how a macro can tell the intent of an application as it links it. There has not been a chmod so that it knows this is setuid and needs more protection. For example, if coreutils was built with this (and coreutils seems to be correct as is) because it has setuid programs, then would all apps get the PIE/Full RELRO treatment? If so, many of coreutils apps are called constantly by shell scripts. If this were used on tcpdump, would full relro leak to the libpcap? I suppose I could test this as soon as I set up a rawhide vm...but this is what concerns me about the approach. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tuesday, August 09, 2011 09:20:53 AM Matthew Garrett wrote: > > Taking RHEL6 through common criteria and FIPS-140, filing dozens of > > security bugs after studying some problems and sending patches. I am > > monitoring the FESCO ticket, but I don't monitor fedora-devel all the > > time because there are way too many arguments for my taste. Regardless, > > should there not have been some hint about anything on the ticket? I > > responded to any review request for the wiki page and such. > > You can't bring a policy to FESCO, fail to turn up to any of the > meetings I didn't fail to turn up to any of the meetings. I watched the issue and attended until it was approved. I then turned my attention to other things like how to scan a distribution to find packages that need updating. I posted a link to my script on the ticket. Just adding a global LDFLAGS accomplishes most of what is needed. The only issue left is when you have a daemon/setuid/setgid/setcap or something parsing untrusted media. Those are all the kind of packages that the maintainer should be skilled enough that they ought to know how to add flags since they would be attack vectors. > and then be surprised if the enacted proposal doesn't perfectly > match yours. The ticket was flagged "meeting" up until the point where > it was closed which means it's under active consideration, and the > meeting summaries posted to fedora-devel contained the various proposals > and action items that we worked through. I would rather have seen a macro added to auto tools to detect gcc support for this so that upstream developers can more easily add the support natively for all distributions. > > My main concern is that the macro will be misapplied and overall > > performance will take a hit. I don't know how a macro can tell the > > intent of an application as it links it. There has not been a chmod so > > that it knows this is setuid and needs more protection. For example, if > > coreutils was built with this (and coreutils seems to be correct as is) > > because it has setuid programs, then would all apps get the PIE/Full > > RELRO treatment? If so, many of coreutils apps are called constantly by > > shell scripts. If this were used on tcpdump, would full relro leak to > > the libpcap? I suppose I could test this as soon as I set up a rawhide > > vm...but this is what concerns me about the approach. > > The aim was to come up with a policy that is straightforward for > maintainers to implement. Making it more complex for small performance > benefits (coreutils applications may be called often, but they're also > pretty tiny - have you actually measured a significant difference in > real world cases?) The compiler folks objected to enable full relro/pie across the board, so I assume they know there is a penalty and we should heed their advice. > increases the risk that someone will make a mistake > and we'll ship code that's less secure than it was supposed to be. That is why I developed a lot of test scripts...so that we check the distribution for security issues. All you need to do is get an install everything setup, and run ./rpm-chksec --all it will grade all the installed packages to see if the comply (with the exception of the parses untrusted media use case). I also have a bunch of other test scripts here: http://people.redhat.com/sgrubb/security if you want to check the distro more. > Like anything, it's a tradeoff. If it causes problems then we can tweak > the implementation, and if you'd prefer you can think of this as a > starting point. Nothing FESCO comes up with is set in stone. We'll be > happy to modify the policy in response to technical feedback. OK. Thanks, -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Friday, August 19, 2011 03:41:33 AM Tim Waugh wrote: > On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote: > > It's not so much cups start up being slow as discovering network > > printers. That can take up to a minute I think. > > This is true... however, discovered printers are cached so this is only > an issue the first time CUPS starts after installation (or after > connection to a new network). If CUPS is enabled by default, can this be done for runlevel 5 only? It should not be enabled by default for servers. > Additionally there are plans afoot to use Avahi for CUPS <-> CUPS > printer discovery, replacing the current "send a broadcast packet every > 30s" protocol. This would eliminate the problem entirely. All security guidance says turn off or get rid of avahi. We really don't want to require it just to print. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Friday, August 19, 2011 10:50:51 AM Richard Hughes wrote: > On 19 August 2011 13:35, Steve Grubb wrote: > > All security guidance says turn off or get rid of avahi. We really don't > > want to require it just to print. > > Then "security" is flying in the face of usability. Generally there is that tension. The main objections is that it makes discovering system resources easy, which in terms of security is bad. It also used to punch a hole in the firewall and add routing rules. All of this is bad for security. If you are catering to a laptop crowd that wants to share music and pictures then avahi is no concern. If however you want a secure by default server OS, then avahi needs to default to disabled. The concern is when its allowed by default, then people might start relying on it to the extent that its impossible to remove later. For example, cups is used as part of the LSPP certification. People running in a LSPP configuration would be horrified to know avahi is now required for printing top secret documents. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Friday, August 19, 2011 10:38:59 AM Ola Thoresen wrote: > On 19. aug. 2011 16:00, "Jóhann B. Guðmundsson" wrote: > > On 08/19/2011 12:35 PM, Steve Grubb wrote: > >> On Friday, August 19, 2011 03:41:33 AM Tim Waugh wrote: > >>> On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote: > >>>> It's not so much cups start up being slow as discovering network > >>>> printers. That can take up to a minute I think. > >>> > >>> This is true... however, discovered printers are cached so this is only > >>> an issue the first time CUPS starts after installation (or after > >>> connection to a new network). > >> > >> If CUPS is enabled by default, can this be done for runlevel 5 only? It > >> should not be enabled by default for servers. > > > > There are no such things as run levels in systemd but yeah desktop > > related services should just be enabled when booting into the graphical > > target. > > Just a thought - would it make sense to create a "server-target" (and/or > "desktop-target") that is independent of graphical-target? I would hope there are pre-canned targets for different crowds. I also hope there is a secure default configuration for each of them. I also hope there is a way to list all of these targets and what is enabled for each one, because that will be needed for any kind of security analysis. > I know I like to have GUI available - also on my servers - as it makes > searching for fixes and bugreports easier when I have to log in on the > console. > > Or is that just redundant, and I'll just have to turn off cups (and > other services I don't need) as before? I hope not. That would be a step backwards in usability and security. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Friday, August 19, 2011 11:24:39 AM Tim Waugh wrote: > On Fri, 2011-08-19 at 11:03 -0400, Steve Grubb wrote: > > People running in a LSPP configuration would be horrified > > to know avahi is now required for printing top secret documents. > > Just to clarify: it is not required. Most likely in an LSPP > configuration not even CUPS Browsing is used, but explicit queues are > set up on each client machine. Thanks for that information. As long as we never lose that ability and avahi can be switched off or removed then all is well. Thanks, -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Friday, August 19, 2011 11:12:25 AM Tomasz Torcz wrote: > On Fri, Aug 19, 2011 at 11:07:45AM -0400, Steve Grubb wrote: > > On Friday, August 19, 2011 10:38:59 AM Ola Thoresen wrote: > > > On 19. aug. 2011 16:00, "Jóhann B. Guðmundsson" wrote: > > > > On 08/19/2011 12:35 PM, Steve Grubb wrote: > > > >> On Friday, August 19, 2011 03:41:33 AM Tim Waugh wrote: > > > >>> On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote: > > > >>>> It's not so much cups start up being slow as discovering network > > > >>>> printers. That can take up to a minute I think. > > > >>> > > > >>> This is true... however, discovered printers are cached so this is > > > >>> only an issue the first time CUPS starts after installation (or > > > >>> after connection to a new network). > > > >> > > > >> If CUPS is enabled by default, can this be done for runlevel 5 only? > > > >> It should not be enabled by default for servers. > > > > > > > > There are no such things as run levels in systemd but yeah desktop > > > > related services should just be enabled when booting into the > > > > graphical target. > > > > > > Just a thought - would it make sense to create a "server-target" > > > (and/or "desktop-target") that is independent of graphical-target? > > > > I would hope there are pre-canned targets for different crowds. I also > > hope there is a secure default configuration for each of them. I also > > hope there is a way to list all > > There was some talk about ”preset” - what should be enabled in various > scenarios (spins). So, the main Fedora download is not sufficient? We have to download a server spin to have the right security settings? If so we should also take way the ability to pick packages because someone might accidentally create a server at install time. We need a way to specify in the service init files which targets the service is allowed to run in by default. > > of these targets and what is enabled for each one, because that will be > > needed for any kind of security analysis. > > System settings: > % ls /lib/systemd/system/.target.wants/ > Admin settings: > % ls /etc/systemd/system/.target.wants/ What would be nice is to wrap that up in a program, format it into columns for easy comparison. Once you have that it might even be nice to use the same tool to make configuration changes -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote: > Tim Waugh wrote: > > Oh, I just noticed this: > > > > https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa > > tion "Since Fedora currently doesn't want any services to do on-demand > > loading, all socket activated services must autostart." > > What the heck?! We're disabling systemd's main feature there, aren't we? > Wasn't the main design concept behind systemd the observation that > everything can be parallelized most effectively by on-demand activation? Why is bootup speed so important that init now has become network aware? Process 1 gets special protection from the kernel. You cannot kill it. If there is any mistake in its code, then you have an unkillable all powerful process that might do rogue things. It almost sounds like this is reinventing Xinetd - except its not as feature rich as xinetd. We had a lot of problems with xinetd over the years. For example, if it listens for a connection that the service must accept and then the service fails before it can call accept, xinetd will spin in a tight loop because the the listen socket is readable and the service is not calling accept. Then lets look at the accept option. If systemd accepts a connection and passes it to a child process, do you now support tcp_wrappers so that you deny the connection before starting the child? That would mean any flaw in tcp_wrappers now is part of process 1 which has special protection from the kernel. How do you limit the number of children? Xinetd grew all these features because of security problems. Xinetd had many bugs because of these features. I personally think systemd's configure should have an --enable-networking. I think this should be turned off. A network aware init could be internet worm material since you cannot kill process 1. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Saturday, August 20, 2011 02:17:04 PM Lennart Poettering wrote: > On Sat, 20.08.11 09:41, Steve Grubb (sgr...@redhat.com) wrote: > > On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote: > > > Tim Waugh wrote: > > > > Oh, I just noticed this: > > > > > > > > https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_ac > > > > tiva tion "Since Fedora currently doesn't want any services to do > > > > on-demand loading, all socket activated services must autostart." > > > > > > What the heck?! We're disabling systemd's main feature there, aren't > > > we? Wasn't the main design concept behind systemd the observation that > > > everything can be parallelized most effectively by on-demand > > > activation? > > > > Why is bootup speed so important that init now has become network aware? > > Process 1 gets special protection from the kernel. You cannot kill it. > > If there is any mistake in its code, then you have an unkillable all > > powerful process that might do rogue things. It almost sounds like this > > is reinventing Xinetd - except its not as feature rich as xinetd. > > systemd never reads a single packet from any of the network sockets it > listens on on behalf of services. It just passes these sockets off to > the services as soon as traffic is seen on them (i.e. when POLLIN is > triggered we pass off the socket, we don't call read() on it.) And therein lies one of the big problems that xinetd has. If its listening and passes the descriptor to a child to accept and the child crashes or aborts before accepting the socket, the whole mess spins in a circle where the listen descriptor is readable, but nothing is accepting the connection. But still, why is speed so important that xinetd capabilities are the answer? Why not leave init not network aware and let xinetd do the on demand startup? This has the advantage of being able to kill xinetd whereas init cannot be killed. > > Then lets look at the accept option. If systemd accepts a connection and > > passes it to a child process, do you now support tcp_wrappers so that > > you deny the connection before starting the child? > > We do tcpwrap checks for incoming connections. I do wonder though > whether it might be time to deprecate tcpwrap distribution-wide. I am > pretty sure firewalls are the better approach, more widely supported, > more widely understood and more widely used. Do you remember the hole in netfilter a while back? CVE-2001-1572 CVE-2006-4572 Its happened before and it will happen again. I'm sure this list is not complete. Then some tools that help setup the firewall might accidentally leave you open: CVE-2003-0080 Belt and suspenders! Must have both. > > That would mean any flaw in tcp_wrappers now is part of process 1 > > which has special protection from the kernel. > > We are very careful with what we execute in PID 1. For example we make > sure not to do any NSS lookups or use other code that might pull in > arbitrary libraries into PID 1. And following this logic I carefully > made sure that tcpwrap checks are not done in PID 1, but in the forked > off process shortly before we execute the process binary. > > And anyway, I wouldn't overestimate the risk here. tcpwrap does not read > from the socket, it just executes syscalls like getsockname() and > getpeername() and suchlike, but does not parse potentially dangerous > network traffic. I wrote lots of patches for tcp_wrappers, mostly to give it ipv6 capabilities. But there were bugs fixed. For example, it provides many functions with names that are in glibc. Which means you might get tcp_wrapper's implementation rather than glibc's. My version was called socket_wrappers and it fixed a whole lot of the problems in tcp_wrapper. So, even if you fork with the intention of not using its code in process 1, you might accidentally be using it. readelf -s /lib64/libwrap.so.0.7.6 | grep FUNC | grep -v UND Looks like someone has been doing some cleanining up, but maybe not that way on other distros. But anyways, tcp_wrapper does reverse DNS lookups to compare the forward and reverse paths in case anyone has tampered with the remote DNS to make it look like the incoming connection is legit. So, may it does not read much off the socket, its does a recvfrom peek, but it does talk with remote DNS servers to make a decision. Not all DNS servers are legit and can be malicious. One incoming packet can cause a cascade of outgoing DNS querries. > > I personally think systemd's configure should have an > > --enable-networking. I think this should be turned off. A network aware > > init could be intern
Re: Default services enabled
On Sunday, August 21, 2011 05:22:17 PM Genes MailLists wrote: > On 08/21/2011 05:09 PM, Steve Clark wrote: > >>> http://0pointer.de/blog/projects/systemd.html > >>> > >>> Read the part about "Parallelizing Socket Services". It explains why > >>> socket actviation is interesting, > >> > >> I find a secure OS interesting. Bootup speed does not matter much to me. > > > > Obviously a lot on this list value boot up speed over security! > > Obviously, anyone who values security over bootup speed has the right > values. > > I share those values as should everyone who is clueful :-) The thing I think about is that is if the solution for parallelizing boot is an xinetd replacement, was there any thought to just patching xinetd? As a former upstream maintainer (and former because its not actively developed nor passed along to another caretaker), we would have taken patches that added AF_UNIX or dbus activation if we understood the need. As proof, Rob added rendezvous support before it went into its unmaintained state. Imagine an updated xinetd + upstart. Would that not solve the problems, cause less turmoil, and be more secure? -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Sunday, August 21, 2011 08:01:33 PM Rahul Sundaram wrote: > On 08/22/2011 05:24 AM, Steve Grubb wrote: > > Imagine an updated xinetd + upstart. Would that not solve the > > problems, cause less turmoil, and be more secure? > > How? Fedora has talked about moving to systemd much before the Fedora > 14 release. Sorry, I was very busy at the time. I am just beginning to look to the future and what might be coming my way for RHEL7 common criteria. I have a hard time with systemd being network aware. The requirements going into RHEL7 will likely be meeting what was known as GPOSPP which includes requirements for a minimal Intrusion Prevention System. Its also a harder protection profile than we have ever met. With init performing an xinetd role, I can't see how I am to kill it when it goes rogue. > It was postponed to Fedora 15, has become the default in that release and we > have > already migrated dozens and dozens of services and we are nearing the Fedora > 16 > Alpha release shortly and aiming for 100% conversion by the general release. I know. I added support in our audit package, but not upstream. I am not convinced yet this is a sound design. How many major throw away subsystems have we seen over the years? The code may be perfectly implemented. But do we really want to design systems with a new, expanded attack surface? This is a design problem that is more secure as separate processes. (Going from sysvinit to upstart was no problem because the attack surface change is minimal.) > How is moving *back* now to upstart going to be less turmoil? You're not seeing the hundreds - no thousands of emails about systemd? You are not seeing that all the expected facilities of init are not covered? There is well founded rebellion here. How do I see all targets on a system? List all services enabled/disabled for each target in one shot? Chkconfig is not perfect, but its a trusted friend. Also, not preparing for both server/desktop targets at a minimum seems problematic in my opinion. > I understand that you are busy and paying attention to this matter only now > but I > can't consider this as a serious proposal. I am wondering if it was ever considered to give xinetd a makeover? I bet the coding would have been done in 2-3 weeks tops. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
Hello, I didn't want to continue this discussion until I have a working F16 setup. Recently something got fixed so that install now works...so... On Tuesday, August 09, 2011 10:39:26 AM Adam Jackson wrote: > On Tue, 2011-08-09 at 08:47 -0400, Steve Grubb wrote: > > My main concern is that the macro will be misapplied and overall > > performance will take a hit. > > That's a valid concern, but any hardened build would have this problem. > I'm happy to talk about how the performance impact can be mitigated, but > it seems unfair to blame a convenience macro for being convenient. I have been trying to test this macro and I see that something does get pulled into the build: cc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -- param=ssp-buffer-size=4 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 But testing the resulting binaries doesn't show any effect. Was this macro and any dependencies pushed out? I have redhat-rpm-config-9.1.0-15.fc16.noarch installed. > I was not attempting to enforce a policy here. I was attempting to make > applying hardened build flags easy in the common case. The problem is that if the "now" flag leaks into shared objects, then all programs linking against it will be slowed down. > > If this were used on tcpdump, would full relro leak to the libpcap? > > I'm not sure why you raise this concern in this particular context, I'm sorry, I was not very clear in what I meant. I intended to ask if you used the macro, would the library also being built pick up the "now" flag and therefore become full relro itself. I hope to answer this for myself, but I don't seem to be seeing any effect from the macro right now. > Thus we can conclude that full- or partial-relro-ness is a per-object > property, and that fully hardening an entire runtime-linked image > requires hardening all of its components. This isn't entirely > surprising, but it's nice to not be surprised. (Yes, Dmitri, it's good > to be fine.) Agreed. > The question then becomes which libraries you want to so harden. Again, > this is a judgement call and I was not intending to imply that this > would be applied globally; if I had, it wouldn't have been a macro at > all. (Of course it's a friendly call.) For the case of tcpdump we > could probably reasonably say all of its deps should be hardened: > > % LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc tcpdump -h |& grep reloc > 14319: relocation processing: /lib64/libz.so.1 (lazy) > 14319: relocation processing: /lib64/libdl.so.2 (lazy) > 14319: relocation processing: /lib64/libc.so.6 > 14319: relocation processing: /usr/lib64/libpcap.so.1 (lazy) > 14319: relocation processing: /lib64/libcrypto.so.10 (lazy) > 14319: relocation processing: tcpdump (lazy) > 14319: relocation processing: /lib64/ld-linux-x86-64.so.2 What we are intending at the moment is partial relro for libraries unless the PLT is small. There had been a suggestion to make a tool that would examine it and if it were small enough suggest that it be made full relro. It was never determined how small is small enough. It would be a good area for someone to research. > zlib is historically a CVE fest, pcap handles untrusted data by design, > libcrypto is almost definitely worth hardening. For the case of libdl I > suspect the glibc maintainers may have a functional reason to want it to > not be -z now, but I've not investigated in that level of detail. Performance. They hardened everything they felt they could. We do need to work on how big the PLT can be before performance is impacted. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Monday, August 22, 2011 08:32:57 PM Lennart Poettering wrote: > On Mon, 22.08.11 17:19, Adam Williamson (awill...@redhat.com) wrote: > > On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote: > > > On 08/22/2011 07:07 PM, Adam Williamson wrote: > > > > On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote: > > > >>> -Steve > > > >> > > > >> Obviously a lot on this list value boot up speed over security! > > > > > > > > You're making a false assumption, which is that socket activation is > > > > only about speed. It's also about resource usage. (There may be other > > > > advantages I haven't considered, this is not to be considered an > > > > exclusive list.) I think it was mentioned before that systemd is consuming a lot of memory. > > > Mmmm Adam - not sure I'd give up security for a little resource > > > saving > > > > > > either ... if indeed that is the trade-off ... > > > > Well, there's a question of whether you're really giving up security. > > There's no actual vulnerability at issue here, just the theory that > > systemd is more susceptible to vulnerabilities. And that is important. If there is a threat, we have to mitigate the possibility through good design. Why is postfix composed of several cooperating processes where sendmail is not? Is there a difference in their security reputations? Why would that be? > As mentioned a couple of times systemd does not read a single network > packet, hence I'd claim systemd is no worse than sysvinit+xinetd+a lot > of stuff, yet a lot more powerful. (xinetd processes a lot of crazy > network protocols internally, and one could argue that it hence is > actually much worse here than systemd. Also, since it duplicates service > execution in two daemons the amount of code to audit is doubled.) Not really. init should be small and not really developed on all the time. Xinetd would need auditing every upstream release...but there hasn't been any in a long time. But one of the things that it does is work correctly with MLS. If a network packet comes in at top secret, it starts the daemon at top secret. I believe that systemd would start the daemon ranged from system high to low - which is wrong. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
DISA STIG file permission testing
Hello, I do a lot of work on making sure Linux meets various security standards. One of the better known security profiles is the DISA STIG. (STIG means Security Technical Information Guide.) Back in February, there was a big update to it. I have reviewed it and sent feedback to get some items corrected. But in the mean time, I wanted to check how far off we have gotten and wrote a script to do some checking. The guide requires a UMASK of 027 for users, so you may find that home dir file permissions are not right. However, if you just create a user and have never logged in...the file permissions should be right. In any event, I have uploaded the scripts so that file permission problems can be found and fixed. The original guide can be found here: http://iase.disa.mil/stigs/downloads/zip/unclassified_os-srg-unix_v1r1_finalsrg.zip We used openscap to translate the XCCDF content into html. The (uncorrected) settings can be found here: http://people.redhat.com/sgrubb/files/stig-2011/stig-2011-checklist.html and the test script can be found here: http://people.redhat.com/sgrubb/files/stig-2011/stig-file-test.sh I think we should realign some file permissions. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Move a configuration file
On Sunday 07 March 2010 11:55:11 am Johan Cwiklinski wrote: > If I change the path in conf.d/BackupPC.conf ; users who have modified > the .conf file will get a conf.rpmnew file ; that's fine. > The ones who did not change the .conf file will have it replaced by RPM, > breaking the apache authentication. > > Any thoughts about that? I think the traditional fix is to have a post install script that checks the old location and moves/copies it to the new location. If this can be done during a period where the config file is not getting features added, its more likely to not cause any problems. Also note that any change in location of important files is likely to affect SE Linux labeling. Policy may have to get adjusted and you might need to coordinate the change so both get pushed out at the same time. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVE-2009-2904 - not patched F11 openssh?
On Friday 26 March 2010 07:25:53 pm Michał Piotrowski wrote: > Vulnerability described in CVE-2009-2904 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2904 was > addressed in https://rhn.redhat.com/errata/RHSA-2009-1470.html for > RHEL. Isn't F11 openssh version also vulnerable? RHEL5 uses version 4.3. The CVE was caused by a flaw in a patch that backported a feature from 4.8 to 4.3. Fedora 11 is on 5.2, so it should not be vulnerable. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVE-2009-2904 - not patched F11 openssh?
On Saturday 27 March 2010 09:17:55 am Steve Grubb wrote: > On Friday 26 March 2010 07:25:53 pm Michał Piotrowski wrote: > > Vulnerability described in CVE-2009-2904 > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2904 was > > addressed in https://rhn.redhat.com/errata/RHSA-2009-1470.html for > > RHEL. Isn't F11 openssh version also vulnerable? > > RHEL5 uses version 4.3. The CVE was caused by a flaw in a patch that > backported a feature from 4.8 to 4.3. Fedora 11 is on 5.2, so it should > not be vulnerable. More research...looks like this took care of it: * Mon Sep 21 2009 Jan F. Chadima - 5.2p1-6 - remove homechroot patch So if you are on 5.2p1-6, you should be OK. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVE-2009-2904 - not patched F11 openssh?
On Saturday 27 March 2010 04:17:13 pm Michał Piotrowski wrote: > > So if you are on 5.2p1-6, you should be OK. > > This upgrade should be pushed to updates-testing and updates > > yum --enablerepo=updates-testing upgrade openssh > [..] > openssh x86_64 5.2p1-5.fc11 updates-testing > 265 k I'll see that this is pushed out as soon as we can. In the meantime, you can grab it here: http://koji.fedoraproject.org/koji/buildinfo?buildID=132898 -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using capabilities for libpcap apps
On Tuesday 06 April 2010 04:47:22 pm Radek Vokál wrote: > I need few suggestions about this .. > https://blog.wireshark.org/2010/02/running-wireshark-as-you/ .. Gerald > Combs, the upstream maintainer of wireshark, suggests to use > capabilities instead of consolehelper+root privileges for > dumpcap/wireshark. It makes whole lot of sense, so I've looked if other > apps in Fedora are already using it and I haven't found any. Honestly > I'm not sure about right way to use them. The idea is to add something > like following to %post > > # groupadd -g wireshark > # chgrp wireshark /usr/bin/dumpcap > # setcap cap_net_raw,cap_net_admin+eip /usr/bin/dumpcap > # setcap cap_net_raw,cap_net_admin+eip /usr/bin/tshark > > Suggestions? Ideas? Spec file patches? rpm supposedly has native support for capabilities. That would mean that you don't need to call setcap. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Libs with applications
Hello, I was curious how many library packages we have that also includes applications in them, so I wrote a small shell script: http://people.redhat.com/sgrubb/security/lib-bin-check On my F16 installation, it finds around 60 packages that are libraries with applications. I'd like to ask if anyone else sees this as a problem? For example, if a 32 bit library is installed, which application is left - the 64 or 32 bit one? And wouldn't that also pull in unnecessary dependencies? -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Libs with applications
On Sunday, November 20, 2011 10:20:51 AM Josh Boyer wrote: > On Sun, Nov 20, 2011 at 10:17 AM, Steve Grubb wrote: > > Hello, > > > > I was curious how many library packages we have that also includes > > applications in them, so I wrote a small shell script: > > > > http://people.redhat.com/sgrubb/security/lib-bin-check > > That just checks for a path. It doesn't check if the "application" is > just a shell script, which is noarch. OK, simple fix. I'll post an improved script in a little while. > > On my F16 installation, it finds around 60 packages that are libraries > > with applications. I'd like to ask if anyone else sees this as a > > problem? For example, if a 32 bit library is installed, which > > application is left - the 64 or 32 bit one? And wouldn't that also pull > > in unnecessary dependencies? > > Again, not if it's noarch. The list of packages you found with > problems would have been nice. After I fix the script, I'll post the packages. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Libs with applications
On Sunday, November 20, 2011 10:26:09 AM Steve Grubb wrote: > On Sunday, November 20, 2011 10:20:51 AM Josh Boyer wrote: > > On Sun, Nov 20, 2011 at 10:17 AM, Steve Grubb wrote: > > > Hello, > > > > > > I was curious how many library packages we have that also includes > > > applications in them, so I wrote a small shell script: > > > > > > http://people.redhat.com/sgrubb/security/lib-bin-check > > > > That just checks for a path. It doesn't check if the "application" is > > just a shell script, which is noarch. New script posted. This dropped the list by about half. > > > On my F16 installation, it finds around 60 packages that are libraries > > > with applications. I'd like to ask if anyone else sees this as a > > > problem? For example, if a 32 bit library is installed, which > > > application is left - the 64 or 32 bit one? And wouldn't that also pull > > > in unnecessary dependencies? > > > > Again, not if it's noarch. The list of packages you found with > > problems would have been nice. libreport-gtk-2.0.6.x86_64 libgnome-2.32.1.x86_64 libtar-1.2.11.x86_64 libreport-newt-2.0.6.x86_64 libgpg-error-1.10.x86_64 libEMF-1.0.4.x86_64 libnotify-0.7.4.x86_64 libselinux-2.1.6.x86_64 libiptcdata-1.0.4.x86_64 libsamplerate-0.1.8.x86_64 libkgeomap-2.3.0.x86_64 libgnomekbd-3.2.0.x86_64 libmsn-4.2.x86_64 libmx-1.4.0.x86_64 libreport-2.0.6.x86_64 libxslt-1.1.26.x86_64 libvirt-0.9.6.x86_64 libcanberra-0.28.x86_64 libtunepimp-0.5.3.x86_64 libidn-1.22.x86_64 libcanberra-gtk3-0.28.x86_64 libgnome-media-profiles-3.0.0.x86_64 libhangul-0.0.12.x86_64 libcroco-0.6.2.x86_64 libkactivities-6.1.x86_64 libieee1284-0.2.11.x86_64 libgpod-0.8.2.x86_64 libwnck3-3.2.1.x86_64 But this is just my system and not an everything install. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Libs with applications
On Sunday, November 20, 2011 02:14:09 PM drago01 wrote: > On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler wrote: > > Steve Grubb wrote: > >> For example, if a 32 bit library is installed, which application is left > >> - the 64 or 32 bit one? > > > > If you install ONLY the 32-bit multilib, the 32-bit version. > > If you install BOTH the 64-bit and 32-bit packages, the 64-bit version > > (on all the platforms where 64-bit is preferred, which includes x86_64 > > and now also ppc64). > > If you install ONLY the 64-bit package, the 64-bit version. > > Yeah which means there isn't really a problem here. Well, yeah there is the other problem of dependencies and getting a smaller minimal install. For example, libnotify. # ldd /usr/bin/notify-send | wc -l 44 # ldd /usr/lib64/libnotify.so.1.2.3 | wc -l 12 or how about libmsn # ldd /usr/bin/msntest | wc -l 20 # ldd /usr/lib64/libmsn.so.0.3.0 | wc -l 9 I didn't test all of them, but the extra dependencies are unneeded. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: Ruby 1.9.3 landed in Rawhide
On Monday, February 06, 2012 09:31:50 AM Bohuslav Kabrda wrote: > Ruby 1.9.3 has finally made it into Rawhide, there are still few more > packages that need to be built, but otherwise the transitions was > successful. > > Please note again, that soname has been bumped to 1.9.1 and license is > changed from GPLv2 or Ruby to BSD or Ruby, as already announced. Would have been nice if this project had kicked off rebuilds like other soname bump projects do. :) I'm finding a problem with my package. According to the http://fedoraproject.org/wiki/Packaging:Ruby guidelines, I should be doing the ruby_sitearch macro. But this seems to point to /usr/local/lib64/ruby/site_ruby/ and I would have expected it to be somewhere else like /usr/lib64/ruby/... Did this really change to /usr/local/lib64/ruby/? The "local" part is throwing off my package. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: Ruby 1.9.3 landed in Rawhide
On Saturday, February 11, 2012 11:32:09 AM Toshio Kuratomi wrote: > On Sat, Feb 11, 2012 at 10:42:53AM -0500, Steve Grubb wrote: > > On Monday, February 06, 2012 09:31:50 AM Bohuslav Kabrda wrote: > > > Ruby 1.9.3 has finally made it into Rawhide, there are still few more > > > packages that need to be built, but otherwise the transitions was > > > successful. > > > > > > Please note again, that soname has been bumped to 1.9.1 and license is > > > changed from GPLv2 or Ruby to BSD or Ruby, as already announced. > > > > Would have been nice if this project had kicked off rebuilds like other > > soname bump projects do. :) I'm finding a problem with my package. > > According to the http://fedoraproject.org/wiki/Packaging:Ruby > > guidelines, I should be doing the ruby_sitearch macro. But this seems to > > point to /usr/local/lib64/ruby/site_ruby/ and I would have expected it > > to be somewhere else like /usr/lib64/ruby/... > > > > Did this really change to /usr/local/lib64/ruby/? The "local" part is > > throwing off my package. > > The new ruby package changed the rpm macros before the new packaging > guidelines for ruby were (they're still pending but hopefully will be > approved by next Wed) approved. So I believe they want to change from > %ruby_site* to %ruby_vendor*. This portion of the new Guidelines isn't > controversial to the FPC (FPC did implicitly assume that this change was > arrived at via the whole Ruby SIG rather than just the ruby pakage > maintainer, though -- if this is in error, please let us know) so it's not > ideal but seems reasonable to update your package to use > %ruby_vendorarchdir now that they've pushed out a package that uses these > new macros. Normally you have to define that in your spec file. What's the magic text to define that? Also, I like keep my spec file as identical as possible between all Fedora releases. Would I have any problem on F16/15 using the same macro? -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: Ruby 1.9.3 landed in Rawhide
On Saturday, February 11, 2012 12:57:40 PM Toshio Kuratomi wrote:
> On Sat, Feb 11, 2012 at 11:41:48AM -0500, Steve Grubb wrote:
> > On Saturday, February 11, 2012 11:32:09 AM Toshio Kuratomi wrote:
> > > On Sat, Feb 11, 2012 at 10:42:53AM -0500, Steve Grubb wrote:
> > > > On Monday, February 06, 2012 09:31:50 AM Bohuslav Kabrda wrote:
> > > > > Ruby 1.9.3 has finally made it into Rawhide, there are still few
> > > > > more packages that need to be built, but otherwise the transitions
> > > > > was successful.
> > > > >
> > > > > Please note again, that soname has been bumped to 1.9.1 and license
> > > > > is changed from GPLv2 or Ruby to BSD or Ruby, as already
> > > > > announced.
> > > >
> > > > Would have been nice if this project had kicked off rebuilds like
> > > > other soname bump projects do. :) I'm finding a problem with my
> > > > package. According to the
> > > > http://fedoraproject.org/wiki/Packaging:Ruby guidelines, I should be
> > > > doing the ruby_sitearch macro. But this seems to point to
> > > > /usr/local/lib64/ruby/site_ruby/ and I would have expected it to be
> > > > somewhere else like /usr/lib64/ruby/...
> > > >
> > > > Did this really change to /usr/local/lib64/ruby/? The "local" part is
> > > > throwing off my package.
> > >
> > > The new ruby package changed the rpm macros before the new packaging
> > > guidelines for ruby were (they're still pending but hopefully will be
> > > approved by next Wed) approved. So I believe they want to change from
> > > %ruby_site* to %ruby_vendor*. This portion of the new Guidelines isn't
> > > controversial to the FPC (FPC did implicitly assume that this change
> > > was arrived at via the whole Ruby SIG rather than just the ruby pakage
> > > maintainer, though -- if this is in error, please let us know) so it's
> > > not ideal but seems reasonable to update your package to use
> > > %ruby_vendorarchdir now that they've pushed out a package that uses
> > > these new macros.
> >
> > Normally you have to define that in your spec file. What's the magic text
> > to define that? Also, I like keep my spec file as identical as possible
> > between all Fedora releases. Would I have any problem on F16/15 using
> > the same macro?
>
> I haven't looked into the rawhide packages where this is implemented (and
> the macro files themselves weren't posted to the ticket where the FPC is
> reviewing the new Guidelines) so I can't tell you 100% for sure.
>
> I'm guessing that the answer is going to be no. But you may be able to
> work around that with:
>
> %{!?ruby_vendorlibdir: %global ruby_vendorlibdir DEFINITIONHERE}
>
> Note that I've just been reviewing the latest additions to the draft
> guidelines and some of the information there may lead to an even more major
> overhaul of the guidelines before they go final.
>
> https://fedorahosted.org/fpc/ticket/134
I guess I could just disable building ruby bindings and no longer support that
language. Would anyone miss libprelude bindings for ruby? Not sure if there is
a
fedora process for dropping support of a language,
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Access rights for system logs
On Friday, February 25, 2011 03:13:31 am Matthias Runge wrote: > - change systems logs owners from root:root mode 600 to root:adm mode > 640 (or something similar) So, what would be the implementation of this? How would logcheck or any log reader work. Would they be setgid applications or would they start as root and change to this new account? There are things in the logs that ordinary users cannot have access to to by default. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Granting a capability to a service
On Saturday, July 18, 2015 10:42:43 AM Florian Weimer wrote: > Let's assume I want to start a service as an ordinary user, but allow to > bind it to a privileged port. The program implementing the service does > not manipulate capabilities in any way. > > I came up with with this system unit for testing purposes: > > [Unit] > Description=Test unit > > [Service] > Type=oneshot > ExecStart=/usr/sbin/getpcaps self > Capabilities=cap_net_bind_service+ep > SecureBits=keep-caps > User=fweimer > StandardOutput=journal > > However, this does not work, the capability set remains empty. Is there > a way to achieve what I want? > > The algorithm documented in capabilities(7) suggests that retaining > effective capabilities across an execve system call absolutely requires > file capabilities (the inheritable part). No. You can start off as root, then change to your target uid retaining, then open the socket. Just do it right away. > The only way to bypass that > if you perform the execve call with UID 0 (i.e., the literal UID 0, not > a capability). Using libcap-ng, its 3 lines of code. Assuming the desired uid is 500: capng_clear(CAPNG_SELECT_BOTH); capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, CAP_NET_BIND_SERVICE); if (capng_change_id(500, 500, CAPNG_DROP_SUPP_GRP | CAPNG_CLEAR_BOUNDING)) error(); -Steve > This design is really odd because setting file capabilities always > increases the attack surface (even if it is just the inheritable bits), > and the only alternative appears to modify the service so that it is > capability-aware and switches away from UID 0, and grant sufficient > capabilities so that it can do so. At that point, you can just skip the > configuration in the systemd service and do everything capablity-related > within the program. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Granting a capability to a service
On Monday, July 20, 2015 04:27:35 PM Florian Weimer wrote: > >> The algorithm documented in capabilities(7) suggests that retaining > >> effective capabilities across an execve system call absolutely requires > >> file capabilities (the inheritable part). > > > > > > > > No. You can start off as root, then change to your target uid retaining, > > then open the socket. Just do it right away. > > Sorry, but I don't see the contradiction. > > As far as I can tell, you have to do all this before the execve > (including the socket creation), or after the execve (and then execve > with UID=0). Without resorting to fscaps, it is not possible to set up > the capabilities and user before the execve, and create the socket after > it. Without fscaps with a UID which is not 0, the capabilities are lost > on execve. Today, any application that wants to manipulate capabilities needs to be capability aware. You can use fs based capabilities, but it will be on even for children. This is because clearing the bounding set requires privs. Not to mention, attempting to clear the bounding set means the app is capabilities aware. > >> The only way to bypass that > >> if you perform the execve call with UID 0 (i.e., the literal UID 0, not > >> a capability). > > > > > > > > Using libcap-ng, its 3 lines of code. Assuming the desired uid is 500: > > > > capng_clear(CAPNG_SELECT_BOTH); > > capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, > >CAP_NET_BIND_SERVICE); if (capng_change_id(500, 500, CAPNG_DROP_SUPP_GRP | > >CAPNG_CLEAR_BOUNDING)) error(); > > But this requires changing the implementation of the service, right? Yes. But doing this is so simple, that it shouldn't be a big deal. 3 lines of code. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Granting a capability to a service
On Monday, July 20, 2015 11:09:39 AM Andrew Lutomirski wrote: > On Jul 20, 2015 11:05 AM, "Florian Weimer" wrote: > > On 07/20/2015 05:59 PM, Steve Grubb wrote: > > > Today, any application that wants to manipulate capabilities needs to be > > > capability aware. > > > > The application does not want to manipulate capabilities. I do not want > > to run it as full root. I don't want to add additional SUID/fscaps to > > the file system. > > > > It's somewhat silly to add a privilege escalation hatch to the file > > system in order to run a daemon with *reduced* privileges. > > This is exactly why the ambient caps patch is sitting in -mm. If you want > to read it and email a quick review, that might help it along. :) The real problem with capabilities is there is no way to say, I trust this child process with this capability, but don't let it get inherited beyond this process that I'm about to start. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Granting a capability to a service
On Monday, July 20, 2015 12:45:28 PM Andrew Lutomirski wrote: > On Mon, Jul 20, 2015 at 12:26 PM, Steve Grubb wrote: > > On Monday, July 20, 2015 11:09:39 AM Andrew Lutomirski wrote: > >> On Jul 20, 2015 11:05 AM, "Florian Weimer" wrote: > >> > On 07/20/2015 05:59 PM, Steve Grubb wrote: > >> > > Today, any application that wants to manipulate capabilities needs to > >> > > be > >> > > capability aware. > >> > > >> > The application does not want to manipulate capabilities. I do not > >> > want > >> > to run it as full root. I don't want to add additional SUID/fscaps to > >> > the file system. > >> > > >> > It's somewhat silly to add a privilege escalation hatch to the file > >> > system in order to run a daemon with *reduced* privileges. > >> > >> This is exactly why the ambient caps patch is sitting in -mm. If you > >> want > >> to read it and email a quick review, that might help it along. :) > > > > The real problem with capabilities is there is no way to say, I trust this > > child process with this capability, but don't let it get inherited beyond > > this process that I'm about to start. > > Why would you want to do that? Because you know exactly why the program needs a capability and its not known to have children. Therefore any children must be because of an exploit. The way it is, capabilities are inherited and you can't stop it. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Granting a capability to a service
On Tuesday, July 21, 2015 01:02:25 AM Reindl Harald wrote: > Am 20.07.2015 um 23:34 schrieb Steve Grubb: > > On Monday, July 20, 2015 12:45:28 PM Andrew Lutomirski wrote: > >> On Mon, Jul 20, 2015 at 12:26 PM, Steve Grubb wrote: > >>> The real problem with capabilities is there is no way to say, I trust > >>> this > >>> child process with this capability, but don't let it get inherited > >>> beyond > >>> this process that I'm about to start. > >> > >> Why would you want to do that? > > > > Because you know exactly why the program needs a capability and its not > > known to have children. Therefore any children must be because of an > > exploit. The way it is, capabilities are inherited and you can't stop it > > when you start a service like let say a webserver and take away > capabilities for security reasons than you want *for sure* to have them > also inherited for *any* scripting language calling whatever via system() > > it's expected behavior that settings for a systemd-unit like > capabilities or namespaces are inherited for *every* prcoess of that > service and not just for ExecStart itself leaving children unprotected Sure, there are cases where you know that. But let's take 'ping' as an example of what I'm talking about. It should never have children. If it does, its been exploited. I do not want any capabilities passed to those children. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Thu, 17 Sep 2015 11:07:37 +0300
Alexander Todorov wrote:
> Can somebody comment on the -fstack-protector-all vs
> -fstack-protector-strong issue ? Do we want to change the default for
> %__global_cflags in /usr/lib/rpm/redhat/macros ?
-all is not needed, -strong is the right balance between security and
performance. For example
int add(int a, int b)
{
return a+b;
}
Does that need a stack canary? This is the nature of why some functions
don't get a canary. Whenever knowledge of a stack frame is passed as a
pointer to a function, then -strong will kick in and do a stack check
on return.
To know if the right thing is being done is hard to script. You really
need to see what flags are passed to each source file being compiled.
You just can't get at that from readelf.
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Wed, 16 Sep 2015 19:24:02 +0300 Alexander Todorov wrote: > Including fedora-devel on this topic. > > На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа: > >>> > >>> Question is how to deal with these because they appear to be in > >>> the hundreds ? > >> > >> How many, exactly? We have around 2 SRPMs in the distribution. > > > > From today's Rawhide snapshot my script counted around 4500 > offending packages. You can find links to the script and execution > log here: > http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/ > > > Please let me know which packages need to genuinely be excluded and > what should we do with these packages ? Some will probably be fixed > once they are rebuilt but that may take a while. I have studied this issue for a long time. You cannot say that a package must have a stack canary. Its quite possible that no function is eligible for a stack canary. In good cases, stack-protector-strong only gives 20 - 30% function coverage. It can actually be lower. I have hints on this in my devconf speech a couple years ago. As for FORTIFY_SOURCE, same thing. Gcc may decide that there is no size information available and therefore cannot have a _check function. FORTIFY_SOURCE coverage is lower than the stack protector. Also, the full RELRO thing is a bit oversold. You need it if the executable is PIE, and that's not needed in the general case. There are far worse problems that are easy to fix that are not getting attention. With the RELRO thing, you already have to have an exploit that allows writing arbitrary memory under attacker control. Most vulnerabilities just don't have this quality about them. What is more important is preventing common vulnerabilities from achieving control over execution with simple heap and stack corruption bugs. Hopefully we can start addressing this in F24. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Thu, 17 Sep 2015 13:53:38 +0300
Alexander Todorov wrote:
> На 17.09.2015 в 13:34, Steve Grubb написа:
> > On Thu, 17 Sep 2015 11:07:37 +0300
> > Alexander Todorov wrote:
> >
> >> Can somebody comment on the -fstack-protector-all vs
> >> -fstack-protector-strong issue ? Do we want to change the default
> >> for %__global_cflags in /usr/lib/rpm/redhat/macros ?
> >
> > -all is not needed, -strong is the right balance between security
> > and performance. For example
> >
> > int add(int a, int b)
> > {
> > return a+b;
> > }
> >
> > Does that need a stack canary? This is the nature of why some
> > functions don't get a canary. Whenever knowledge of a stack frame
> > is passed as a pointer to a function, then -strong will kick in and
> > do a stack check on return.
> >
>
> Hi Steve,
> thanks for the explanation.
>
> So it looks like I should ignore stack canary warnings (assuming the
> package is using the default flags). Should this be ignore for both
> libraries and executable binaries or only libraries ? Or the answer
> is once again, you can't tell that easily ?
Not completely. See below.
> > To know if the right thing is being done is hard to script. You
> > really need to see what flags are passed to each source file being
> > compiled. You just can't get at that from readelf.
> >
>
> Is it realistic to request a RFE with this information stored in the
> compiled object and then be read by readelf ? If so I can file bugs
> in bugzilla.redhat.com or upstream .
>
I think Florian answered this. Indeed, the --debug-dump option does
find these strings, but they are mixed in with other data. I think that
if there is no canary and flags were passed, its not a problem. If the
flags are absent, the build scripts are suspect.
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Requiring all files in /usr to be world-readable?
On Sunday, November 02, 2014 06:15:05 PM Lennart Poettering wrote: > On Fri, 31.10.14 10:04, Andrew Lutomirski (l...@mit.edu) wrote: > > I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 > > > > Thoughts? > > I very much agree with this, but I'd really prefer if we'd list what > is allowed rather than just declare what is forbidden. > > A short list like this should be everything we should allow in /usr: > > a) symlinks > b) directories with access mode 0555 > c) files with access mode 0444 (optionally 0644 if owned by root user) > d) files with access mode 0555 (optionally 0755 if owned by root user) > e) files with access mode 2555 (optionally 2755 if owned by root user) > f) files with access mode 4555 > > Or something like that. > > That said, there appears to be some form of cargo-cult programming > around, for example the audit packages carries a lot of non-sensical > access modes, for security theatre reasons. Good luck with getting > that package fixed! Today's guru meditation: He who lives in glass house should not throw stones. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
On Friday, June 5, 2020 5:42:36 AM EDT Vít Ondruch wrote: > Dne 05. 06. 20 v 9:52 Kevin Kofler napsal(a): > > > Ben Cotton wrote: > > > >> == Summary == > >> Fedora has historically forced packages to build with GCC unless the > >> upstream project for the package only supported Clang/LLVM. This > >> change proposal replaces that policy with one where compiler selection > >> for Fedora follows the package's upstream preferences. > >> > >> == Owner == > >> * Name: Jeff Law > >> * Email: l...@redhat.com > > > > I am opposed to this change. Chromium and Firefox build fine with GCC. I > > > > think that a distribution should be built with a consistent toolchain > > wherever possible. > > > > Last I checked, there were several reasons why GCC is preferred over > > Clang/LLVM in Fedora. And if that should ever change (or have changed > > already), then switching the systemwide default (reversing the rules, > > i.e., using GCC only for those packages that do not build with Clang) > > should be envisioned. But as far as I know, that is not the case at this > > time, considering runtime performance, security features, etc. > > > > I do not see why we should allow yet another special case for Firefox, > > nor why we should let random packages make their own choice of > > compiler and risk running into hidden binary incompatibilities. We have > > a system compiler for a reason. > > Just FTR, there are technical (and security) reasons why we might > consider switching Ruby from GCC to Clang in the future: > > https://bugzilla.redhat.com/show_bug.cgi?id=1721553 I don't think allowing builds with Clang are necessarily bad. It has one interesting feature that actually helps security. -ftrivial-auto-var-init=zero what this does is initialize to zero any variable that it detects is uninitialized. This can prevent leaking secrets in network protols if memset was forgotten and it prevents attacks where the value of the stack or heap is groomed to a certain value to enable an exploit. In one conference presentation, it was said that 900 fixed CVE's in Chrome and 12% of all Android CVE's would have been prevented with this feature. I am wondering if that should be a default flag for clang builds? And if you do fuzzing, you can compile AFL with clang and its more powerful. There's pro's and cons. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is allowed in certain cases to override default Fedora compiler flags?
On Wednesday, July 1, 2020 4:47:51 PM EDT Sergio Belkin wrote:
> The line in the code is :
>
> if(upLogPerror) ::write(2,logbuf,n); \
>
> Regarding to " format not a string literal and no format arguments
> [-Werror=format-security]" message.
> Afaik instructions of kind printf(format,var1,var2,...) always be fail,
> since it can't verify in compile time that the format includes the number
> of variables that appears later.
>
> If the developer does not use entered formats by the user, the exploit
> disappear, doesn't it?
>
> So the question is: in this case I can override the Fedora compiler flags?
This is pointing to a potential exploit in the code. In general, this is the
pattern its detecting
char user_input[BUF_SIZE];
get_user_input(user_input);
printf(user_input);
The fix is to change the printf to
printf("%s", user_input);
Hope this helps...
-Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Building kernel rpms with KASAN enabled
Hello, What is the best way to build an official Fedora kernel SRPM with KASAN=y? TIA, -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: urandom vs haveged
On Monday, March 26, 2012 03:56:43 PM Chris Murphy wrote: > Performance: > > dd if=/dev/zero ~56MB/s CPU < 10% > dd if=/dev/urandom~12MB/s CPU 99% > haveged ~54MB/s CPU < 25% > > > The dd relative values are consistent with kernels in Fedora 16. However > these tests were done with 3.3.0-1. The questions are: > > Is the urandom performance expected? I get this: # dd if=/dev/zero of=/dev/null 4775272+0 records in 4775271+0 records out 2444938752 bytes (2.4 GB) copied, 4.12342 s, 593 MB/s # dd if=/dev/urandom of=/dev/null 118512+0 records in 118511+0 records out 60677632 bytes (61 MB) copied, 8.0117 s, 7.6 MB/s On ^^ quadcore using 2.6.35.14 kernel. I would say this is somewhat expected because /dev/zero does nothing while /dev/urandom stirs in system entropy and hashes it before letting it out. > What is the quality of pseudo-random data produced by urandom vs haveged? The quality of urandom is very good. Its studied every couple years for common criteria purposes. Haveged on the other is never used in common criteria and its properties are largely unknown. From its home page: HAVEGE (HArdware Volatile Entropy Gathering and Expansion) is a user-level software unpredictable random number generator for general-purpose computers that exploits these modifications of the internal volatile hardware states as a source of uncertainty Unpredictable means someone needs to do a lot of study to determine if there are predictable cycles to it. Does it have scheduler artifacts in its numbers? What if the hardware its using is not available during system installation? Does it work on all platforms? Does it do any conditioning of its entropy sources? Does it quality check its numbers before sending them out? > If the qualities are similar, or haveged's is better, is there anything > that can be done to improve urandom's performance? Possibly. I don't know if anyone has looked at making it faster or studied where the bottleneck is. It does produce very high quality numbers and its well studied, though. That has always been the prime focus. Something else I'd like to mention is that during system installation there is very little system entropy. There is no saved seed to prime the generators with. (LiveCD's have the same problem.) I have a feeling that the randomness of the numbers is not what you would expect. If you have a mouse attached and are doing a graphical install, then waving the mouse around will make sure you have entropy. But if you don't have a mouse and are doing a text or kickstart install, you need to find a way to get keystrokes involved. If you can think of a key that has no effect on any questions in the install, hit it a bunch of times. If you have a kickstart, put something in the script requiring typing a bunch of keystrokes and throw them away. In a way, if encrypted disks are being created at install time, Anaconda might want to measure entropy before creating the keys and optionally allow you to add keystrokes or wave the mouse around or startup rngd to gather entropy from a tpm chip or rdrand instructions. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Monday, April 02, 2012 03:58:12 PM Richard W.M. Jones wrote: > > * #834 F18 Feature: /tmp on tmpfs - > > > > http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) > > * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) > > Actually I think this is a good feature, but ... What about forensics? Any reboot erases information that might have been needed to see what happened during a break in. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Audit overhead and default rules
On Monday, February 10, 2014 11:05:38 AM Andrew Lutomirski wrote: > On a default Fedora installation, every system call incurs a fair > amount of overhead due to syscall auditing. This happens despite the > fact that syscalls aren't actually audited, except as part of AVC > denials. > > The overhead is something like 20-40ns per syscall, and the total time > to do a simple syscall with auditing completely disabled is about 70ns > on my laptop. So this is actually a large effect. Then pass -s=nochange on the auditd command prompt. This means that auditd will not attempt to enable auditing. When auditing is not enabled, it will not build an audit context and syscalls are slightly faster, but you will loose a tiny bit of information that selinux would have liked to have. > What would people think about changing the default audit rules to add > something like '-t task,never'? This filter is almost useless. Its never used in real life because it creates inauditable processes which is exactly opposite of what people normally want. > This would remove the overhead, but it would come at the cost of removing > the syscall records from > /var/log/audit/audit.log when an AVC denial occurs. > > This could make debugging selinux errors a bit harder, but it would be > easy for users to re-enable full auditing. > > I've been playing with fixing this in the kernel, but it's a mess. Its also simple to fix in your config. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Audit overhead and default rules
On Monday, February 10, 2014 12:10:27 PM Andrew Lutomirski wrote: > On Mon, Feb 10, 2014 at 12:06 PM, Steve Grubb wrote: > > On Monday, February 10, 2014 11:05:38 AM Andrew Lutomirski wrote: > >> On a default Fedora installation, every system call incurs a fair > >> amount of overhead due to syscall auditing. This happens despite the > >> fact that syscalls aren't actually audited, except as part of AVC > >> denials. > >> > >> The overhead is something like 20-40ns per syscall, and the total time > >> to do a simple syscall with auditing completely disabled is about 70ns > >> on my laptop. So this is actually a large effect. > > > > Then pass -s=nochange on the auditd command prompt. This means that auditd > > will not attempt to enable auditing. When auditing is not enabled, it will > > not build an audit context and syscalls are slightly faster, but you will > > loose a tiny bit of information that selinux would have liked to have. > > > >> What would people think about changing the default audit rules to add > >> something like '-t task,never'? > > > > This filter is almost useless. Its never used in real life because it > > creates inauditable processes which is exactly opposite of what people > > normally want. > > It's also the only way to turn off TIF_SYSCALL_AUDIT in current > kernels. I'm not attempting to justify the sanity of that; I'm just > reading the code. Not enabling audit also causes TIF_SYSCALL_AUDIT to not be placed in the process's flags. You have 2 choices: 1) performance 2) audit. They are necessarily mutually exclusive. > >> This would remove the overhead, but it would come at the cost of > >> removing > >> > >> the syscall records from > >> /var/log/audit/audit.log when an AVC denial occurs. > >> > >> This could make debugging selinux errors a bit harder, but it would be > >> easy for users to re-enable full auditing. > >> > >> I've been playing with fixing this in the kernel, but it's a mess. > > > > Its also simple to fix in your config. > > There are, indeed, many ways for me to fix this on my machine. I'm > suggesting that Fedora change the default so that no one has > experiences this overhead by default. There are 3 levels of audit performance degradation. 1) audit is disabled. You get full speed 2) audit is enabled and no rules. This is the default for Fedora so that more information can be collected when AVC's occur. 3) audit is enabled and rules loaded. This does get a performance hit that can be measured. In this case, the person wanted auditing and is willing to take any performance hit it may incur. The audit system has been set for #2 for the last 8 or 9 years as a balance between getting information for avc's, not taking a big performance hit, and keeping setup easy for when people want to add auditing to their system. > If the default gets changed, I > don't particularly care *which* change is made, so long as the effect > is that TIF_SYSCALL_AUDIT doesn't get set (so there's no overhead) but > that AVC denials still get logged (which I suspect is the overwhelming > majority of the value added by audit support). AVC's should be logged with or without audit being enabled. Auditd will collect any avc sent to it by selinux even if audit is disabled. Please try adding -s=nochange to your config and see how that works for you. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Audit overhead and default rules
On Monday, February 10, 2014 12:41:08 PM Andrew Lutomirski wrote: > >> There are, indeed, many ways for me to fix this on my machine. I'm > >> suggesting that Fedora change the default so that no one has > >> experiences this overhead by default. > > > > There are 3 levels of audit performance degradation. > > 1) audit is disabled. You get full speed > > 2) audit is enabled and no rules. This is the default for Fedora so that > > more information can be collected when AVC's occur. > > 3) audit is enabled and rules loaded. This does get a performance hit that > > can be measured. In this case, the person wanted auditing and is willing > > to take any performance hit it may incur. > > > > The audit system has been set for #2 for the last 8 or 9 years as a > > balance > > between getting information for avc's, not taking a big performance hit, > > and keeping setup easy for when people want to add auditing to their > > system. > > Right. I'm proposing changing the default from #2 to #1. I forgot to mention option 0) audit package not installed. I don't think the audit package is mandatory and that would be the default. But if you do install the audit package its assumed you want auditing in some capacity and are willing to take the minimal hit. You also get more audit events such as promiscuous socket use, user space events, and a couple other kernel events that are security related. > I think that #2-by-default is a terrible tradeoff. I suspect I've debugged > more selinux denials than the average user, and I have *never* *once* > looked at a 'syscall' entry in the log. The selinux people wanted the syscall event. Once upon a time, you used to have to add a rule to get the syscall information. But they decided they want more information by default. I would suggest reverting that patch as a test. I think the problem was that they needed a file path sometimes and would ask people to add an audit rule like "-w /etc/shadow -p w". But then the user wouldn't get a recurrence and they couldn't really fix the problem very fast. The exact details may be different, but I think this is the gist of it. > I think that subjecting every Fedora user by default to 20-40 ns of extra > syscall latency for the sole benefit of getting those 'syscall' messages is a > bad tradeoff. I don't think all Fedora users have audit installed and would not see the hit. > I'm willing to write kernel code to improve the situation. The > problem is that getting rid of TIF_SYSCALL_AUDIT when there are no > audit rules configured is messy. Better suggestions are welcome. The problem is getting TIF_SYSCALL_AUDIT back in all processes when auditing is enabled. We cannot stop the OS and stab that flag into all processes when audit gets re-enabled. Its best not to play with that flag. The kernel logic is supposed to be something like if (tif & TIF_SYSCALL_AUDIT) if (current->audit_context) if (audit_ever_enabled) audit_syscall_entry() So, the overhead when disabled should only be an if statement or two. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Friday, March 14, 2014 03:00:20 PM Matthew Garrett wrote: > > I disagree with this assessment. The workstation is exactly where much of > > these hardening needs to take place. I can't see an installation that > > wouldn't benefit from this feature. > > If there's a default policy that would make sense for most workstation > users, we should just make that the default. Right now there is just one policy. In there future there could be several. I could see a server specific, workstation specific, virt specific, PCI, USGCB, STIG, common criteria, etc. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: > On Fri, Mar 14, 2014 at 02:51:10PM -0400, Steve Grubb wrote: > > On Friday, March 14, 2014 03:00:20 PM Matthew Garrett wrote: > > > If there's a default policy that would make sense for most workstation > > > users, we should just make that the default. > > > > Right now there is just one policy. In there future there could be > > several. I could see a server specific, workstation specific, virt > > specific, PCI, USGCB, STIG, common criteria, etc. > > Having separate server, workstation and cloud products means we can > apply separate defaults without requiring user interaction. Beyond that, > why would an end user want to choose common criteria during an > interactive install? Isn't that something that should be imposed on them > by their local admin? Yes, and I believe the kick start would do that. I would also even see a case where an admin takes the base policy and tailors it with site specific settings and puts that into effect instead of the default one we provide. I like the idea of choice. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DISTRIBUTION tag seems wrong
Hello,
Not sure if this is bz worthy or just something to mention on a mail
list. I was doing some experimenting on creating SWID tags out of the
rpm database and noticed some inconsistencies. For example:
# rpm -q --queryformat '%{DISTRIBUTION}\n' bash
Fedora Project
# rpm -q --queryformat '%{DISTRIBUTION}\n' xbmc
Fedora 20
Seems that rpmfusion has it right and the main Fedora build system is
misconfigured.
Also...
# rpm -q --queryformat '%{PACKAGER}\n' bash
Fedora Project
# rpm -q --queryformat '%{PACKAGER}\n' xbmc
Re: DISTRIBUTION tag seems wrong
On Wed, 7 May 2014 19:02:57 +0400
Igor Gnatenko wrote:
> > Not sure if this is bz worthy or just something to mention on a mail
> > list. I was doing some experimenting on creating SWID tags out of
> > the rpm database and noticed some inconsistencies. For example:
> >
> > # rpm -q --queryformat '%{DISTRIBUTION}\n' bash
> > Fedora Project
> > # rpm -q --queryformat '%{DISTRIBUTION}\n' xbmc
> > Fedora 20
> >
> > Seems that rpmfusion has it right and the main Fedora build system
> > is misconfigured.
>
> I think first right. How about EPEL?
If that's true, what tag should output Fedora 20? Something should. We
also have the VENDOR tag and that is Fedora Project. I think that is
the right place for Fedora Project.
-Steve
> > Also...
> >
> > # rpm -q --queryformat '%{PACKAGER}\n' bash
> > Fedora Project
> > # rpm -q --queryformat '%{PACKAGER}\n' xbmc
> >
Re: DISTRIBUTION tag seems wrong
On Wed, 7 May 2014 11:53:30 -0500
Dennis Gilmore wrote:
> > Not sure if this is bz worthy or just something to mention on a mail
> > list. I was doing some experimenting on creating SWID tags out of
> > the rpm database and noticed some inconsistencies. For example:
> >
> > # rpm -q --queryformat '%{DISTRIBUTION}\n' bash
> > Fedora Project
> > # rpm -q --queryformat '%{DISTRIBUTION}\n' xbmc
> > Fedora 20
> >
> > Seems that rpmfusion has it right and the main Fedora build system
> > is misconfigured.
>
> rpmfusion has it wrong, they should be using rpmfusion. koji sets the
> distribution tag for everything that is built in the buildsys to be
> the same. for fedora that is "Fedora Project" as that is who is
> building and distributing the rpms
OK, maybe I am approaching this from the wrong direction. What I need
to identify in the rpm database is the following:
1) product title - this would be the rpm package name
2) product version - again version from rpm
3) software creator - was thinking this was URL
4) software licensor - was thinking this was VENDOR
5) component_of - was thinking that this was DISTRIBUTION
It doesn't seem right to have 4 & 5 say Fedora Project. In a sense its
true. But I was wanting the component_of to say Fedora 20 or 19 so that
the tag contents better identify an OS component to match reality. If
we have the same version of a package on F19 & F20, the way it is now,
all identification will be the same but the file hashes will be
different because of timestamps, compiler options, different
definitions of macros & inline functions, etc. Hope this clarifies
things a bit.
Thanks,
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F24 System Wide Change: Default Local DNS Resolver
On Monday, November 30, 2015 01:50:54 PM Russell Doty wrote: > Is DNS by itself sufficient, or should we also address other network > facing capabilities with security impact such as secure time? The use case for the dnscache_test is to look for evidence of a system trying to reach a known Command and Control system. This would indicate that the server has malware on it. I believe that examining DNS cache by itself is sufficient. -Steve > On Mon, 2015-11-30 at 17:14 +0100, Jan Kurik wrote: > > = Default Local DNS Resolver = > > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > > > Change owner(s): > > * P J P > > * Pavel Šimerda > > * Tomas Hozza > > * Petr Špaček > > > > Plain DNS protocol is insecure and therefore vulnerable from various > > attacks (e.g. cache poisoning). A client can never be sure that there > > is no man-in-the-middle, if it does not do the DNSSEC validation > > locally. > > We want to have Unbound server installed and running on localhost by > > default on Fedora systems. Where necessary, have also dnssec-trigger > > installed and running by default. Unbound and dnssec-trigger will be > > properly integrated with the default network configuration manager > > (e.g. NetworkManager for Fedora Server and Workstation) and with the > > graphical user interface (especially GNOME). The localhost address > > will be the only record in /etc/resolv.conf and no other software > > except dnssec-trigger will be allowed to change its content. > > > > > > > > == Detailed Description == > > Plain DNS protocol is insecure and therefore vulnerable from various > > attacks (e.g. cache poisoning). DNSSEC is a DNS extension which > > enabled the client to verify the DNS query response and make sure > > there is no attacker to spoof some records. A user connected to > > network usually receives a set of resolvers from DHCP, which should > > be > > used for name resolution. These resolvers may also do the DNSSEC > > validation. However a client can never be sure that there is no > > man-in-the-middle, if it does not do the DNSSEC validation locally. > > Purpose of this Fedora change is to have a validating DNS resolver > > installed on Fedora systems by default. This includes necessary > > discussions, coordination and integration with other components > > installed on Fedora by default. > > > > There are growing instances of discussions and debates about the need > > for a trusted local validating DNS resolver. There are multiple > > reasons for having such a resolver, most importantly security and > > usability. Security and protection of user's privacy becomes > > paramount > > with the backdrop of the increasingly snooping governments and > > service > > providers world wide. > > > > People use Fedora on portable/mobile devices which are connected to > > diverse networks as and when required. The automatic DNS > > configurations provided by these networks are never trustworthy for > > DNSSEC validation, as currently there is no way to establish such > > trust. > > > > Apart from trust, these name servers are often known to be flaky and > > unreliable which only adds to the overall bad and at times even > > frustrating user experience. In such a situation, having a trusted > > local validating DNS resolver not only makes sense but is, in fact, > > badly needed. It has become a need of the hour. (See: [1], [2], [3]) > > > > All DNS literature strongly recommends it and amongst all discussions > > and debates about the issues involved in establishing such trust, it > > is unanimously agreed upon and accepted that having a trusted local > > DNS resolver is the best solution possible. It will simplify and > > facilitate a lot of other design decisions and application > > development > > in the future. (See: [1], [2], [3]) > > > > [1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html > > [2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html > > [3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755 > > .html > > > > > > > > == Scope == > > Proposal owners: Proposal owners shall have to > > * define the syntax and semantics for new configuration > > parameters/files. > > * properly document how to test and configure the new default setup > > * persuade and coordinate with the other package owners to > > incorporate > > new changes/workflow in their applications. > > * discuss with WGs in which products the change makes sense and what > > are the expectations of WGs for different Fedora products > > * resolve interoperability issues for Docker and other containers use > > -cases > > > > Other developers: (especially NetworkManager and the likes) > > * NetworkManager has to implement notifications on connectivity state > > changes > > * Gnome Shell has to use the connection provided resolvers (fetched > > directly from NM) for Hot-Spot login purposes > > * Ideally other developers and user should test their software and > >
How do you unsubscribe from mdapi meta-data update?
Hello, Something started sending me emails about $SUBJECT. The email says this is due to my preferences and give an URL. Clicking on that URL leads to a page that says, "Transaction expired, or cookies not available. Try to login again." Logging in again leads to no useful page. It simply says "You will be redirected to this application whenever another application requires you to authenticate." Reclicking the original link still says I'm not logged in. Logging into my FAS account does not allow me to pick any preference about this email. How does one stop it? Why is the URL that the email gives wrong? -Steve -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How do you unsubscribe from mdapi meta-data update?
On Wednesday, December 16, 2015 11:44:54 AM Kevin Fenzi wrote: > On Wed, 16 Dec 2015 10:19:50 -0500 > > Steve Grubb wrote: > > Hello, > > > > Something started sending me emails about $SUBJECT. The email says > > this is due to my preferences and give an URL. Clicking on that URL > > leads to a page that says, "Transaction expired, or cookies not > > available. Try to login again." > > > > Logging in again leads to no useful page. It simply says "You will be > > redirected to this application whenever another application requires > > you to authenticate." > > > > Reclicking the original link still says I'm not logged in. Logging > > into my FAS account does not allow me to pick any preference about > > this email. How does one stop it? Why is the URL that the email gives > > wrong? > > Can you share the url it's giving you? > > It should be something like: > > https://apps.fedoraproject.org/notifications/.id.fedoraproject > .org/ https://apps.fedoraproject.org/notifications/sgrubb.id.fedoraproject.org/email/27154 > Which should redirect you to the Fedora ipsilon auth server. > It sounds like it is redirecting you, but somehow it thinks you have > taken too long to login and says the transaction is expired? Yes. And logging in still doesn't help. The email seemed to allude that following that link would allow me to fix my preferences. > In any case you can go to: > > https://apps.fedoraproject.org/notifications/ > > click the 'login button' and login. > Then you should be able to add a filter to drop those notifications. Thanks. Will give that a try. -Steve -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: remove polkit from core?
On Saturday, November 10, 2012 09:26:26 AM Richard W.M. Jones wrote: > On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: > > Matthew Miller wrote: > > > Apparently the new version of polkit brings in javascript. The js > > > package > > > is 6.5MB. I think anything that uses polkit will depend on it -- can we > > > remove it from core? > > > > Of course, the real question is why the heck PolicyKit needs a Turing- > > complete rule language (which also forced everyone to port their existing > > rules) when the previously-used simple INI-style pkla rule format did the > > job just fine! > > And Unix groups worked OK before that (and still do for the majority > of purposes). Another problem is how would we do SCAP configuration checks when the language will allow 20 different ways to do the same thing? We might be able to do a SHA256 has of the js. Which means you've completely lost any ability to modify the behaviour. In an ini file, we could pick out the lines that were important and check them only allowing other settings we don't care about to change. Additionally, access control decisions should be audited. There are no libaudit bindings for javascript. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Monday, November 12, 2012 12:27:52 PM Dan Williams wrote: > On Sat, 2012-11-10 at 02:33 +0100, Kevin Kofler wrote: > > Matthew Miller wrote: > > > Apparently the new version of polkit brings in javascript. The js > > > package > > > is 6.5MB. I think anything that uses polkit will depend on it -- can we > > > remove it from core? > > > > Of course, the real question is why the heck PolicyKit needs a Turing- > > complete rule language (which also forced everyone to port their existing > > rules) when the previously-used simple INI-style pkla rule format did the > > job just fine! > > So that more complex rules-parsing can be done instead of hardcoded > rules. For example, when creating a new WiFi network, NetworkManager > could pass along the security options, network details, even the user > that requested creating it. Administrator-written rules can factor all > those details into the decision whether to allow/deny, which the > existing static rules simply cannot do. except that most admins will never be able to do this. The only people that get any flexibility are people who manage their own system. Everyone else likely has some compliance issues and they have to be verifiably in configuration. What will happen is the generic js file will be SHA256 hashed and we'll check the file's hash in SCAP and report the system as out of configuration. IOW, anyone running any sizeable operation just lost any flexibility. > Whether or not JS should be a *hard* dependency of PolicyKit, I don't > know. But the feature is valuable, so don't dismiss it out-of-hand. I think its a bad idea to have too much flexibility for access control systems. They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG or any other standard, you have to be able to demonstrate you are in the approved config. No one can write a test that can tell if the rules really are sound. So, what will happen is one set will be chosen for better or worse, it will be SHA256 hashed. And no one can change anything in it without being out of compliance. The benefit of the name=value setup is that we can pick out the things that matter and skip everything else which truly gives flexibility when needing to demonstrate compliance. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Monday, November 12, 2012 08:15:48 PM Miloslav Trmač wrote: > On Mon, Nov 12, 2012 at 7:54 PM, Kevin Kofler wrote: > > Jan Zelený wrote: > >> Yes, that's the plan. But dnf is still Python. So if we really want to > >> get Python out of minimal install, there is a room for possible > >> alternatives I guess. > > > > Right. We need to stop writing core system components in scripting > > languages! > > Well, there are significant advantages to using a higer-level > language than C.[1] But the problem I see is a lot of libraries are wrapped by swig, which leaks memory like a sieve. If swig didn't generate such leaky code, Python based daemons wouldn't be as scary. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tuesday, November 13, 2012 12:50:11 PM Alek Paunov wrote: > Hi Steve, > > On 12.11.2012 21:00, Steve Grubb wrote: > > I think its a bad idea to have too much flexibility for access control > > systems. They have to be verifiable. If you have to comply to PCI-DSS or > > the DISA STIG or any other standard, you have to be able to demonstrate > > you are in the approved config. No one can write a test that can tell if > > the rules really are sound. So, what will happen is one set will be > > chosen for better or worse, it will be SHA256 hashed. And no one can > > change anything in it without being out of compliance. > > > > The benefit of the name=value setup is that we can pick out the things > > that > > matter and skip everything else which truly gives flexibility when needing > > to demonstrate compliance. > > My question is: Whether be acceptable the required compliance analysis > to be performed on rules written in simplified rule language like > Datalog instead of imperative scripted evaluation in some future version > of polkit ... ? The standard that everyone is embracing for compliance checking is called SCAP. Parts of it are also being looked at by the IETF for standardization, too. I did a presentation on SCAP for the aqueduct project here: https://fedorahosted.org/aqueduct/attachment/wiki/Call/intro-SCAP-tech- talk.pdf XCCDF represents the policy that you wish to enforce. It is abstract in that it does not know exactly what file to access or how to perform the check. That is the job of OVAL, which is concrete in that it has the exact tests and knows which file to look at. The OVAL language has a number of checking mechanisms: http://oval.mitre.org/language/version5.10.1/OVAL_Language_Specification_01-20-2012.pdf For anything with name=value, we normally use the textfilecontent54 which we can define a regex to pick out the items of interest. However, with a language, you have multiple ways of expressing the same idea. for example, if (foo() > 500) and uid = foo(); if (uid > 500) and start = 500; uid = foo(); if (uid > start) do the same thing. Then throw in comments and indentation and it you have lots of possibilities. This is also not considering whether the code actually meets the intent or allows unintended functionality (exploits). The only thing I can think of, using what's currently available in SCAP is to use filehash58 and call it a day. This has the drawback of notifying the admin that the hash doesn't match instead of a useful, actionable, message. They will be left wondering why the hash doesn't match and what they can do to fix it. This is not going to help security. This should be a lesson to anyone wanting to adopt a languge for system configuration and policy decision. > (It seems to me that e.g. Datalog is good enough both as flexibility and > static analysis (symbolic evaluation), furthermore IMO declarative rules > are less error prone for sysadmins than scripting) Do you have a reference for it? I would almost think that you would want to specify system access rights in a Formal Language which supports the notion of proofs if anything like this were done. In that event, standards work would have to be done in preparation for this. I sit on the OVAL editorial Board, so I could raise the issue to the Board. But javascript for access control policy is a train wreck for anyone needing to demonstrate compliance. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tuesday, November 13, 2012 09:37:07 AM Steve Grubb wrote: > For anything with name=value, we normally use the textfilecontent54 which we > can define a regex to pick out the items of interest. However, with a > language, you have multiple ways of expressing the same idea. for example, > > if (foo() > 500) > > and > > uid = foo(); > if (uid > 500) > > and > > start = 500; > uid = foo(); > if (uid > start) > > do the same thing. Then throw in comments and indentation and it you have > lots of possibilities. This is also not considering whether the code > actually meets the intent or allows unintended functionality (exploits). > > The only thing I can think of, using what's currently available in SCAP is > to use filehash58 and call it a day. This has the drawback of notifying the > admin that the hash doesn't match instead of a useful, actionable, message. > They will be left wondering why the hash doesn't match and what they can do > to fix it. And then if the javascript was found to have a vulnerability in it and it got fixed or perhaps updated to allow smartcard functionality or something...now the hash doesn't match. The old vulnerable hash will be forever encoded into guidance with almost no way to get a standards body to change it. With name = value, the vulnerability would likely be in the compiled code and the compliance check would pass. In this case the settings are verifiably correct because the config file is not changed and part of the compliance check usually involves running the OVAL content the Red Hat security response team generates which checks the rpm version. -Steve > This is not going to help security. This should be a lesson to anyone > wanting to adopt a languge for system configuration and policy decision. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tuesday, November 13, 2012 02:07:53 PM Matthias Clasen wrote: > - Original Message - > > > So, talking about specific actions... > > > > I have recently had to search all existing polkit policies. This is > > no longer possible to automate because various packages ship the > > JavaScript policy, so I had to review those by hand. It seems that > > (perhaps with the exception of polkit itself) any use of JavaScript > > could be converted into the old format, which remains supported. > > > > So, as soon I find some free time (probably next week), I intend to > > ask FPC to prohibit using JavaScript if the functionality can be > > represented in the old .pkla, and to prepare patches to convert the 6 > > JS-using packages. > > Not sure where you got that information. pkla files are not supported > anymore. > > So, converting JavaScript rules to pkla syntax won't do any good. What is > worthwhile doing though, is to review all existing packages that ship such > rules, and stop them from doing that, if possible. JavaScript rules are > only meant for admin use, no OS-provided package should install them. We > only look in /usr/share to allow for the possibility of site-local > configuration that is distributed in packages. Turning system configuration into a scriptable language is like going back in time to the 70's and early 80's where you modified the source to have a different behavior. Remember Basic programs where if you wanted it to do something new, you change your copy so its better that the one people were sharing? It was decided a long time ago that its better to just have a parser that looks for the things that people would commonly like to change. This way, you have some assurance that the main binary has some integrity and you didn't make some kind of typo that opens access for the world. As a matter of fact, the better way to do this is via some kind of daemon that keeps all this information in one giant database. This way its possible to audit any change to the database and know who did it, what they changed, and what the old and new values are. This level of service was asked for by government agencies. We pointed to the sshd config file and said its impossible. I canplace a watch on the file and I can tell you who changed it and I can tell you when they changed it, but I cannot tell you what in it changed. This is the direction I'd rather see the OS go instead of going back to what amounts to changing the source code. We need to improve the verifiablity rather than the flexibility. > A concrete action that we are going to take is to split the polkit daemon > into its own subpackage. Then minimal / certifiable installs can contain > clients that are using the polkit libraries, without pulling in the daemon. > Polkit clients are already expected to handle this situation and fall back > to allow only uid 0. All of this is documented in > > http://www.freedesktop.org/software/polkit/docs/latest/polkit-apps.html We have security configurations for desktop systems. This proposal fixes the minimal install issue but does not address the compliance issue. -Steve http://en.wikipedia.org/wiki/Configuration_file -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tuesday, November 13, 2012 04:41:12 PM Bill Nottingham wrote: > Matthew Miller (mat...@fedoraproject.org) said: > > On Mon, Nov 12, 2012 at 08:07:39PM -0800, Jesse Keating wrote: > > > Yeah, that's a thing that probably could be done. Bug again I'd > > > like some input from people who have made the switch to these > > > packages being mandatory. > > > > Well, I think it's just that the policy for a long time that since core > > isn't visible, default or optional are pointless. Specifically: > > > > http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gr > > oups#Core> > > says (right now, but maybe not for long): > > Core is not visible, so adding 'default' or 'optional' packages to it > > isn't > > needed. Boot loaders are listed as 'default' in the group so that > > they're > > pulled in by compose tools. > > > > That last part isn't even right. There's not too many packages in core, so > > I don't think it'll be that difficult of an excercise to find the > > reasoning for each. > > So, what it is bascially designed for now is: > > - Boot to a normal prompt > basesystem > bash > coreutils > filesystem > glibc > initscripts > plymouth (was for boot logs & encrypted partitions; could be dropped) > rootfiles > setup > systemd > util-linux > (plus implicit kernel) > - Support basic networking > biosdevname (consistent naming policy) > initscripts > dhclient > hostname > iproute > iputils > NetworkManager Shouldn't iptables be here too? > - Connect to remote systems > curl > openssh-clients > - Allow remote systems to connect to us > openssh-server > - Store & forward logs > audit > rsyslog As soon as you have logs, you need to be able to rotate them. So, I'd add logrotate and cronie at this point. Failure to rotate logs can fill the /var partition and then bad things happen. Thanks, -Steve > - Install other software > rpm > yum > - SELinux > policycoreutils > selinux-policy-targeted > - Add/remove/configure local users, and allow them to admin if necessary > passwd > shadow-utils > sudo > - Minimal tools for admins > less > man-db > procps-ng > vim-minimal > - Scheduled tasks > cronie > - Get mail off the box (and define a default for doing so) > sendmail > - Support a local console > kbd > ncurses > - Configure additional partitions for the simple case > e2fsprogs > parted > - Probably legacy and can be dropped from explicit listing > iprutils > ppc64-utils > > Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wednesday, November 14, 2012 08:07:25 AM tim.laurid...@gmail.com wrote: > On Wed, Nov 14, 2012 at 6:53 AM, Ian Pilcher wrote: > > On 11/13/2012 09:50 PM, Matthias Clasen wrote: > > > Yes, this was a misunderstanding. What is still supported is the .policy > > > > files containing the default policy. And that is very good, since such > > policy files are installed by pretty much every package that uses polkit, > > while .pkla files were only used by very few packages. > > > > > > Wait. So the .pkla file I wrote to allow my run virt-manager as my > > normal user is going to stop working, and I'm going to have to write the > > replacement in JavaScript? > > > > Let's just say I'm struggling to find the words ... > > In F18 yes. > > http://davidz25.blogspot.dk/2012/06/authorization-rules-in-polkit.html This blog misses the most important property about security settings...they have to be auditable through automation. If you have 10,000 systems and need to know your security posture, you have to be able to check them through automation. If the javascript had a file over in /etc that it read configuration things from, then we are OK. But if we have to go check the code itself, there is a problem. -Steve > http://www.freedesktop.org/software/polkit/docs/master/polkit.8.html > > Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tuesday, November 13, 2012 04:55:50 PM Adam Williamson wrote: > > So far everything works without, and I think we should endevor to keep > > that true. > > I think this is similar to the firewalld issue in that the basic theory > here is that, look, NetworkManager is the way, the truth and the light: > it's supposed to be the One True Networking System, and we're just > keeping the network service around because there's some stuff it does > that NM doesn't do yet. > > This logic is getting a tad stretched because we've been rolling with it > for several years at this point, but AIUI this is still the party line > and the reason NetworkManager is in core. In theory the idea is not that > we provide, actively maintain and support both NM and the network > service, but that we want to only provide, maintain and support NM, and > we're keeping the legacy 'network service' stuff around only until NM is > done. > > It might be worth re-evaluating whether that's realistic any more, > though, and whether we're really committed to finally replacing > network with NM in some kind of reasonable timeframe. For Common Criteria purposes, everything running as root goes under the microscope and its painful and costly. We have to avoid that. If NM did not run as root and just retained whatever capability it needed, then we have an easier time. Same thing with firewalld. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable kdump on secureboot machines
On Thursday, July 11, 2013 10:33:05 AM Vivek Goyal wrote: > Secondly, there are disagreements upstream w.r.t how locking down > executable should happen. IMA folks want some functionality behind > security hooks (as opposed to what I have done). So I am expecting > that once patches do get merged upstream, they might be in little > different shape altogether. I don't know if the average person has played with IMA. It hashes all files being accessed depending on its policy. This is CPU intensive and will cause the system fans to run faster and the system uses more power. It also runs slower because of all the time spent hashing files. I reported this to upstream IMA developers a while back. I doubt anything has changed. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Friday, July 26, 2013 09:29:41 PM Eric Sandeen wrote: > On 7/26/13 3:13 PM, Miloslav Trmač wrote: > > A quick way to check whether your package is likely to be affected, is > > to look for statfs() or statvfs() calls in C, or the equivalent in > > your higher-level library / programming language. > > statfs will still tell you how much space the filesystem has allocated, > as well as how much space it thinks it has left, based on the total > space the disk has *said* it has available, just like it always ever > did. > > The difference, of course, is that you might actually run out of blocks > before you fill the fs. But I can't think offhand what apps would care. > And again, it's something the admin shouldn't let happen. The audit system also cares about space available. We tell people to create a partition specifically for auditing so that we can keep close track on what's left. But we have the requirement that for people that depend on it to "take away" system access should the ability to record audit events fail. We also need an accurate estimation before we run out so we can send an admin defined warning when the disk has filled to a certain point so that they can archive files or make space available. If we run out of disk space and were not able to warn admins and this was a shop that really cares about auditing, the system will either be shutdown or sent to single user mode for corrective action. So, having accurate space left numbers is real important so that systems don't get shutdown unexpectedly. -Steve > For now, consider it completely transparent to the user (unless the > admin doesn't keep up, in which case it will be anything *but* > transparent). > > TBH, when the backing store runs out of space, things do get pretty > ugly at this point. It's work that needs to be done to make it more > robust & graceful. > > -Eric > > > Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Monday, July 29, 2013 01:41:12 PM Chris Murphy wrote: > On Jul 29, 2013, at 1:05 PM, Steve Grubb wrote: > > The audit system also cares about space available. We tell people to > > create a partition specifically for auditing so that we can keep close > > track on what's left. > > How does the audit system determine space available? It uses fstatfs() on the descriptor currently opened for logging. -Steve > If it's using btrfs configured for raid1 or raid10, df and stat will report > the total storage of all devices in the volume, unlike md raid (or even > proprietary raid). Instead df reports logs files as using twice as much > space. > > > Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Trousers package changed license to BSD
Hi, The 0.3.11 release of trousers has changed from the CPL license to the 3 clause BSD license. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Expanding the list of "Hardened Packages"
On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote: > On Fri, Mar 29, 2013 at 10:43 PM, Richard W.M. Jones wrote: > > On Fri, Mar 29, 2013 at 10:08:37PM +0530, Dhiru Kholia wrote: > > > 1. Hardening flags should be turned on (by default) for all packages > > > which are at comparatively more risk of being exploited or which meet > > > some well-defined criteria (suggestions welcome). > > > > Is there somewhere which describes what to do / what flags to enable? > > http://wiki.debian.org/Hardening describes the various hardening flags. > > "_hardened_build" rpm spec macro can be used to harden a package. > > For an example, see > http://pkgs.fedoraproject.org/cgit/clamav.git/tree/clamav.spec This flag is overly aggressive. We have a list of programs that need PIE enabled and doing more isn't necessarily constructive. What would be nice is if the autotools got some macros to detect PIE and RELRO support in gcc so that its easy to add to CFLAGS and LDFLAGS so that it can be applied more precisely. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote: > On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb wrote: > > On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote: > > > "_hardened_build" rpm spec macro can be used to harden a package. > > > > > > For an example, see > > > http://pkgs.fedoraproject.org/cgit/clamav.git/tree/clamav.spec > > > > This flag is overly aggressive. We have a list of programs that need PIE > > enabled and doing more isn't necessarily constructive. > > Why exactly it "isn't necessarily constructive"? If you have hard data, > please share :) Because PIE is only supposed to be on long running apps and setuid apps. If its on everything, it will slow the system down too much and then you have the knee jerk reaction to remove it from anything. We want it applied when needed and otherwise not. Also, the hardened macros adds the "now" directive to the linker. This is needed for PIE apps since there is a table for the indirection, but this also adds additional slowdown to startup. Jakub mentioned pretty much the same thing, too much PIE is not a good thing. What we want is a balance between fast and secure. That is how the rpm-chksec script is written. Its coded to grade the distribution based on this philosophy. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote: > On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb wrote: > > On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote: > > > On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb wrote: > > > > On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote: > > > > > "_hardened_build" rpm spec macro can be used to harden a package. > > > > > > > > > > For an example, see > > > > > http://pkgs.fedoraproject.org/cgit/clamav.git/tree/clamav.spec > > > > > > > > This flag is overly aggressive. We have a list of programs that need > > > > PIE > > > > > > enabled and doing more isn't necessarily constructive. > > > > > > Why exactly it "isn't necessarily constructive"? If you have hard data, > > > please share :) > > > > Because PIE is only supposed to be on long running apps and setuid apps. > > If > > its on everything, it will slow the system down too much and then you have > > the > > knee jerk reaction to remove it from anything. We want it applied when > > needed > > and otherwise not. > > How much does it slow things down? I'm fairly certain you don't have any > good data on this point. Dhiru is working out how to best figure out FWIW. > > I'm willing to agree that PIE on x86 is going to be very slow due to > register pressure. However, we should consider revisiting what we want > built as PIE. Is Firefox a long running process? Firefox fits into the category of a parser of untrusted media. Therefore it should hardened. > It is on my system. Revisiting our current list and trying to understand our > needs is never a bad thing to do. Existing architectures are different now > than they were when that list was created, no harm comes from talking about > it. I think the list, if enforced, is good enough for our needs. PIE is only part of the issues. Other things that are more important in my opinion. 1) Heap randomization is only 14 bits! If PIE is enabled, it has 29 bits of randomization. We need to do something about that. 2) Even though we have only a handful of apps violating NX stack, we have a bunch of apps that mmap writable and executabel memory. For example, polkitd running as root has WX memory. Mosty of KDE does, so does Cinnamon. Part of the problem seems to be libjs. What its doing is partially compiling, compiling as needed, optimizes as the script runs. If you look into libjs, you see that it has calls to mprotect to actually solve the problem. However, there is an obvious typo that disables it. So, when you fix that, you find out the actual use of the protections is completely missing. The code is BSD...so maybe the actual use is behind closed doors. 3) We need the -fstack-protector-string patch for gcc. This effectively doubles the coverage of the stack protector. For example, CVE-2013-0288 would have been stopped -fstack-protector-strong. 4) We need to get fortify_source macros into gnulib. Last week I was looking at nspr and wondering why fortify_source was not getting used and found that it wrapped functions for "portability". For example, it has PL_strcpy which only wraps strcpy. The problem is the size information is lost by the wrapping so that the fortify macros have nothing to work with. I know this is a common technique, I've seen it a lot. But this idiom defeats a security mechanism. PIE is a second layer defence. Assuming an attacker has exploited something, it makes ROP harder to do. I'd like to fix some of these other issues that stop attacks at the beginning. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Wednesday, April 10, 2013 03:55:46 PM Miloslav Trmač wrote: > Hello all, > the discussion has somewhat died down... If you have a specific proposal > for a change in policy, please add it to > https://fedorahosted.org/fesco/ticket/1104 ; hard data that demonstrate the > impact, if any, in a situation relevant to Fedora (in particular, taking > into account prelink as it is deployed by default) would be very welcome > but is not a strict requirement. > > (This is not intended to cut off the discussion on the mailing list, only > to make it clear to FESCo whether there is any proposal for change or > whether we are happy enough with the current status.) I don't think there is any need to extend the set of packages that _should_ get hardening. The current guidelines are sufficient. What is not happening is the packages that have apps that fit the need to be hardened are not getting the proper hardening. I have opened dozens of bugs on the "core" packages that matter, but even those bz are still not complete. Bottom line, we just need more prodding of maintainers that have apps that need hardening based on current guidelines. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Friday, April 12, 2013 06:44:33 AM Josh Bressers wrote: > On Thu, Apr 11, 2013 at 12:54 PM, Reindl Harald wrote: > > which is exactly the goal ASLR is desigend for > > It's designed to make certain types of attacks more difficult. It > doesn't make them impossible, just much harder. > > Here is an example. > > When you write a security exploit, you generally have to do things > like call into system libraries to do useful things. Generally you > have a limited amount of room for your exploit's "payload", so the > idea is to just leverage what the system can already do. Calling > system() would be an example of this. Now long ago, before things like > ASLR, if you had access to the binary you wanted to attack, you could > inspect the binary to see what the address of system() was. It didn't > change between runs of the binary, so I could hard code that address > into my exploit. With ASLR, every time you run the binary the address > of various system calls is now basically random (it's not exactly, but > that's an exercise for the reader to figure out). I would like to point out that a non-PIE 64 bit application will only get 14 bits of randomization of the heap. In my opinion, this must be fixed since this is very predictable. Even jemalloc provides 19 bits of heap randomization - which is not ideal, but is better than our current default. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Saturday, April 13, 2013 12:19:42 PM Rahul Sundaram wrote:
> On Sat, Apr 13, 2013 at 11:33 AM, Steve Grubb wrote:
> > I don't think there is any need to extend the set of packages that
> > _should_
> > get hardening. The current guidelines are sufficient. What is not
> > happening is
> > the packages that have apps that fit the need to be hardened are not
> > getting
> > the proper hardening. I have opened dozens of bugs on the "core" packages
> > that
> > matter, but even those bz are still not complete.
>
> Is there a tracker bug? Proven packagers can help
I have a tracker bug for issues identified on the core set of packages that
would be part of a common criteria certification:
https://bugzilla.redhat.com/show_bug.cgi?id=853068
which then shows:
dbus https://bugzilla.redhat.com/show_bug.cgi?id=853152
NetworkManager https://bugzilla.redhat.com/show_bug.cgi?id=853199
I have not run the script that checks a distribution on F19 yet, so maybe
there are more?
http://people.redhat.com/sgrubb/files/rpm-chksec
To check a typical install and only get the packages that do not meet policy,
do this:
./rpm-chksec --all | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g" |
egrep -w 'no|PACKAGE'
A small sample on F18:
PACKAGE RELRO PIE CLASS
abrt-addon-ccpp.x86_64 yesnosetuid
abrt.x86_64 yesnodaemon
accountsservice.x86_64 yesnodaemon
acpid.x86_64yesnodaemon
agave.x86_64no yes exec
akonadi.x86_64 yesnonetwork-local
alsa-lib.x86_64 yesnonetwork-ip
alsa-utils.x86_64 yesnonetwork-ip
apg.x86_64 yesnodaemon
arpwatch.x86_64 yesnodaemon
But it should be noted that the script does not identify parsers of untrusted
media. This would be stuff like: gnash, ooffice, evince, poppler, firefox,
konqueror, xchat, wireshark, eog, kmail, evolution, rpm, etc. I don't know how
to automate that.
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Saturday, April 13, 2013 08:44:44 PM Richard W.M. Jones wrote:
> On Sat, Apr 13, 2013 at 08:36:53PM +0200, Kevin Kofler wrote:
> > Richard W.M. Jones wrote:
> > > (1) -fstack-protector{,-all} doesn't implement full bounds checking
> > > for every C object.
> >
> > But it prevents (with probability (256^n-1)/256^n, where n is the size of
> > the canary in bytes, which for n=4 is approximately .976717)
> > exploiting the overflows to change the return address of any C function.
>
> I said it "doesn't implement full bounds checking for every C object",
> and I stand by that.
It doesn't have to. It only places a canary on the stack without any notion of
size. This technique is pretty effective and ruins most functions that could be
used for ROP gadgets. If the C object is on the heap, then all you have
protecting you from coding mistakes is FORTIFY_SOURCE. It requires size
information at compile time and most of the time its not available.
> I doesn't cover stack objects smaller than some
> cut-off size,
-fstack-protector-all really is all. The default in Fedora is 4 bytes which
would cover cases where ints and char[] are interposed as in some networking
code. But more importantly, the defaul stack-protector only kicks in when the
object is a char array. If its an int array or something exotic like an array
within a struct, it does not kick in. That is what the -fstack-protector-
strong patch provides. Its been floating around the internet and is the default
for chrome OS. All the testing I've done shows it catches all stack overflows
of all kinds. We really need it integrated with Fedora's gcc.
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Saturday, April 13, 2013 12:28:04 PM Jerry James wrote: > > I have not run the script that checks a distribution on F19 yet, so maybe > > there are more? > > > > http://people.redhat.com/sgrubb/files/rpm-chksec > > That script reports all .o files (yes, those are sometimes packaged) > as "exec no no", with a red "no" in the RELRO column. But RELRO > doesn't make any sense for a .o, so perhaps that should be a green > "N/A" instead. Probably. But it has caught a few packages that did not even know they were shipping .o files and they removed them right away. That's a tough one. I can probably fix it to reclassify them not as an exec and that would make the triage easier. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Saturday, April 13, 2013 08:36:53 PM Kevin Kofler wrote:
> > (1) -fstack-protector{,-all} doesn't implement full bounds checking
> > for every C object.
>
> But it prevents (with probability (256^n-1)/256^n, where n is the size of
> the canary in bytes, which for n=4 is approximately .976717)
> exploiting the overflows to change the return address of any C function.
There is the off chance that an attacker correctly guesses the canary value.
:-)
One thing that I found in doing a recent study was that there is a build
system, scons, where our defaults are not getting used during compile. For
example, the zfs-fuse package uses the scons build system. It did not have
PIE, RELRO, stack protector, or FORTIFY_SOURCE anywhere. Anything else that
uses scons should be inspected for similar problems.
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of "Hardened Packages"
On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote:
> which I interpret to mean that after using -fstack-protector-all and
> removing prelink, SELinux would become obsolete because no executable
> can be exploited.
I would say there is a place for SE Linux even if we compiled everything with
"all" because FORTIFY_SOURCE coverage is not absolute. For example, about a
month ago i ran the following test:
procs=`ls /proc | grep '^[0-9]' | sort -n`
for p in $procs
do
res=`cat /proc/$p/maps 2>/dev/null | awk '$2 ~ "wx" { print $2 }'`
if [ x"$res" != "x" ] ; then
cat /proc/$p/cmdline | awk '{ printf "%-35s\t", $1 }'
printf "%s\n" "$p"
fi
done
What this does is display the programs with Writable and Executable memory.
All Fedora desktops except Mate have WX memory. (I checked KDE, Gnome,
Cinnamon, and Mate.) WX memory is dangerous because the normal exploit pattern
is:
1) Allocate executable memory
2) Copy shell code into it
3) Jump to shell code
4) Profit!
The WX memory on virtually all the desktops means Step 1 is completed. All an
attacker needs to do is copy payload to Wx memory and jump to it. SE Linux is
the last line of defence. Of course to be effective, this means that SE Linux
has to have policy around the same applications that parse untrusted media so
that when they are exploited it knows abnormal behavior.
> > And there is no cutoff size with -fstack-protector-all.
All really is all. There is no cutoff. (There is a cutoff for the regular stack-
protector, but we have a good default.) It does not help for heap related
objects, though. What I would prefer rather than "all" is the "strong" patch.
If you have a void function with no local variables, "all" will place a canary
even though one is not needed. However, "strong" will not and that will make
the program run a bit faster. The "strong" patch really represents a good
balance between speed and covering everything that matters.
And at Infiltrate 2013, one new technique for exploitation that was discussed
was pivoting the stack pointer to something like the heap where you might have
executable permissions. I think this was discussed in context to exploiting
ARM systems, but in a post PC world this will be increasingly important.
Also demonstrated at Infiltrate last week was the next kind of attack that
occurs even when you do things nearly perfect. Windows 8 has vastly improved
exploit countermeasures (there is a presentation at BlackHat 2012). For
example, it has guard pages between memory allocations, they changed heap
allocations < 16K (which is the majority of all uses) to be bit mapped based
so there is no possibility heap state attacks. It also randomly assigns blocks
so that behavior is non-deterministic. Sounds hard to exploit?
It turns out there is a weakness. The medium sized allocator has predictable
behavior and its memory gets reused. What the attack demonstrated was that an
attacker can use the Feng Shui technique to cause the placement of memory
allocation of a structure holding a function pointer right beside a vulnerable
buffer so that they can modify the function pointer and then wait for it to get
used. Eric also demonstrated that he could do this in the Windows 8 kernel,
too. So, watch out for function pointers, too. :-)
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Bad file access on the rise
Hello,
Every now and then I look at the distribution to see that from an auditing
perspective the OS is nicely behaving in the absence of intrusion. Meaning we
are not getting audit events unnecessarily. One of the typical rules required
by the DISA STIG is to watch for file access being denied due to permissions.
This could be indicative of someone trying to access something they shouldn't.
The rule is:
-a always,exit -F arch=b64 -S creat -S open -S openat -S truncate -S ftruncate
-F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access
Lately F18 has been showing lots of audit events where access is being denied
opening a file:
# aureport --start today --key --summary
Key Summary Report
===
total key
===
537 access
25 module-load
6 container-config
6 system-locale
6 bypass
This is after using the system for 2 hours. Let's see what files were trying to
be accessed:
]# ausearch --start today -k access --raw | aureport --file --summary | head
File Summary Report
===
total file
===
88 /dev/shm/pulse-shm-838240362
88 /dev/shm/pulse-shm-191856280
88 /dev/shm/pulse-shm-3756395503
7 /dev/shm/pulse-shm-1545675388
6 /usr/share/icons/hicolor/48x48/apps/firefox.png
Let's look at one of these pule-shm events:
# ausearch --start today -k access -f pulse-shm -i --just-one
type=PATH msg=audit(06/07/2013 07:13:46.377:215) : item=0 name=/dev/shm/pulse-
shm-3756395503 inode=25089 dev=00:10 mode=file,400 ouid=gdm ogid=gdm rdev=00:00
obj=system_u:object_r:user_tmpfs_t:s0
type=CWD msg=audit(06/07/2013 07:13:46.377:215) : cwd=/
type=SYSCALL msg=audit(06/07/2013 07:13:46.377:215) : arch=x86_64 syscall=open
success=no exit=-13(Permission denied) a0=0x7fffbeda83c0 a1=O_RDONLY|
O_NOFOLLOW|O_CLOEXEC a2=0x0 a3=0x0 items=1 ppid=2369 pid=2370 auid=sgrubb
uid=sgrubb gid=sgrubb euid=sgrubb suid=sgrubb fsuid=sgrubb egid=sgrubb
sgid=sgrubb fsgid=sgrubb ses=2 tty=(none) comm=pulseaudio
exe=/usr/bin/pulseaudio subj=unconfined_u:system_r:unconfined_t:s0 key=access
So, gdm is creating a file 400 and pulse-audio can't open it. Is it suppose to
be like that?
What about the firefox one?
type=PATH msg=audit(06/07/2013 08:13:52.465:633) : item=0
name=/usr/share/icons/hicolor/22x22/apps/firefox.png inode=16943495 dev=09:01
mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:usr_t:s0
type=CWD msg=audit(06/07/2013 08:13:52.465:633) : cwd=/home/sgrubb
type=SYSCALL msg=audit(06/07/2013 08:13:52.465:633) : arch=x86_64 syscall=open
success=no exit=-1(Operation not permitted) a0=0x7fc3be80e880 a1=O_RDONLY|
O_NOATIME a2=0x0 a3=0x0 items=1 ppid=2395 pid=2670 auid=sgrubb uid=sgrubb
gid=sgrubb euid=sgrubb suid=sgrubb fsuid=sgrubb egid=sgrubb sgid=sgrubb
fsgid=sgrubb ses=2 tty=(none) comm=firefox exe=/usr/lib64/firefox/firefox
subj=unconfined_u:unconfined_r:unconfined_t:s0 key=access
It is using the O_NOATIME flag. To use O_NOATIME requires CAP_FOWNER and
firefox
should no have capabilities. So, how bad is the NOATIME problem?
# ausearch --start today -k access -i | grep NOATIME | awk '{ print $30 }' |
~sgrubb/working/BUILD/numeric-tools/summary
exe=/usr/bin/cinnamon 193
exe=/usr/lib64/firefox/firefox 31
exe=/usr/bin/gnome-terminal12
exe=/usr/bin/nautilus 10
exe=/usr/bin/xchat 4
exe=/usr/bin/nm-applet 2
exe=/usr/bin/kontact 2
This seems to account for a good number of the problematic accesses. Anything
except backup programs using O_NOATIME is probably thinking they are making
the program faster, but instead is failing to open files.
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Friday, June 07, 2013 05:14:30 PM Lennart Poettering wrote: > On Fri, 07.06.13 09:50, Steve Grubb (sgr...@redhat.com) wrote: > > Let's look at one of these pule-shm events: > > # ausearch --start today -k access -f pulse-shm -i --just-one > > > > type=PATH msg=audit(06/07/2013 07:13:46.377:215) : item=0 > > name=/dev/shm/pulse- shm-3756395503 inode=25089 dev=00:10 mode=file,400 > > ouid=gdm ogid=gdm rdev=00:00 obj=system_u:object_r:user_tmpfs_t:s0 > > type=CWD msg=audit(06/07/2013 07:13:46.377:215) : cwd=/ > > type=SYSCALL msg=audit(06/07/2013 07:13:46.377:215) : arch=x86_64 > > syscall=open success=no exit=-13(Permission denied) a0=0x7fffbeda83c0 > > a1=O_RDONLY| O_NOFOLLOW|O_CLOEXEC a2=0x0 a3=0x0 items=1 ppid=2369 > > pid=2370 auid=sgrubb uid=sgrubb gid=sgrubb euid=sgrubb suid=sgrubb > > fsuid=sgrubb egid=sgrubb sgid=sgrubb fsgid=sgrubb ses=2 tty=(none) > > comm=pulseaudio > > exe=/usr/bin/pulseaudio subj=unconfined_u:system_r:unconfined_t:s0 > > key=access > > > > So, gdm is creating a file 400 and pulse-audio can't open it. Is it > > suppose to be like that? > > Yes, it is. 88 times? Something changed. It didn't used to be this bad. Its doing this over and over on the same file it was denied access on previously. > POSIX shared memory doesn't define any useful scheme for automatic > removing of shared memory segments from /dev/shm after use. Hence, in > order to make sure that left-over segments don't fill up /dev/shm > forever PA will try to GC dead segments from /dev/shm on each > start-up. For that it iterates through /dev/shm/pulse-shm*, tries to > read the PID that is stored in there. Maybe the uid can be encoded in the name so that wrong uid's are skipped? > When the PID still exists it goes > to the next file. If the PID doesn't exist it unlinks the file and then > goes to the next one. It's a simple scheme that works around the > limitations of POSIX shm. Of course /dev/shm is a single namespace for > all users, hence not all files can be opened, and that's totally cool > and expected, and they will be skipped. > > Shared memory on Linux is a mess. Not automatic clean up, shmctl(, IPC_RMIDdoesn't help? -Steve > no quota limits, it's a sad story. If you care about security and > reliability, it would be great doing something about this, so that arbitrary > users cannot DoS the system this easily anymore... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Friday, June 07, 2013 05:48:39 PM Lennart Poettering wrote: > On Fri, 07.06.13 11:44, Steve Grubb (sgr...@redhat.com) wrote: > > 88 times? Something changed. It didn't used to be this bad. Its doing this > > over and over on the same file it was denied access on previously. > > Actually all libpulse clients do this. > > > > POSIX shared memory doesn't define any useful scheme for automatic > > > removing of shared memory segments from /dev/shm after use. Hence, in > > > order to make sure that left-over segments don't fill up /dev/shm > > > forever PA will try to GC dead segments from /dev/shm on each > > > start-up. For that it iterates through /dev/shm/pulse-shm*, tries to > > > read the PID that is stored in there. > > > > Maybe the uid can be encoded in the name so that wrong uid's are > > skipped? > > But why? So that you are not filling up the audit logs. There are people that have to use these audit rules and we need a normally operating system to produce as few false positives as possible. > This stuff should be simple, and it's always a better idea to > simply let the kernel do EACCES rather then trying to be smarter than > the kernel and reimplement access control in userspace. Well, you are already trusting the name. Who's to say some rougue process didn't create the file name to try and trick pulseaudio? How about doing like some processes do in the /tmp dir...put the segments in a directory /dev/shm// and then scan all the files that belong to that user? There are ways to make this better if you are willing. :-) Thanks, -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Friday, June 07, 2013 06:21:00 PM Lennart Poettering wrote: > On Fri, 07.06.13 12:09, Steve Grubb (sgr...@redhat.com) wrote: > > > > > POSIX shared memory doesn't define any useful scheme for automatic > > > > > removing of shared memory segments from /dev/shm after use. Hence, > > > > > in > > > > > order to make sure that left-over segments don't fill up /dev/shm > > > > > forever PA will try to GC dead segments from /dev/shm on each > > > > > start-up. For that it iterates through /dev/shm/pulse-shm*, tries to > > > > > read the PID that is stored in there. > > > > > > > > Maybe the uid can be encoded in the name so that wrong uid's are > > > > skipped? > > > > > > But why? > > > > So that you are not filling up the audit logs. There are people that have > > to use these audit rules and we need a normally operating system to > > produce as few false positives as possible. > > Maybe the audit system should be fixed to not trip up by this? As I said before, this rule comes from the DISA STIG. Its not an audit bug, its doing exactly what its supposed to do. Its seeing questionable behavior and logging it. > > > This stuff should be simple, and it's always a better idea to > > > simply let the kernel do EACCES rather then trying to be smarter than > > > the kernel and reimplement access control in userspace. > > > > Well, you are already trusting the name. Who's to say some rougue process > > didn't create the file name to try and trick pulseaudio? > > Well, if the process did that, then we'd just delete his shared memory > block. I don't feel particularly tricked there... ;-) And besides that, > note that PA also checks a file signature before deleting the file, just > to be sure to not delete anything of importance... OK, good. Then we can agree that it only deletes files that look like they belong to pulse audio and because of the sticky bit on /dev/shm, only files you own can be deleted. > > How about doing like some processes do in the /tmp dir...put the > > segments in a directory /dev/shm// and then scan all the > > files that belong to that user? > > Guessable directory names in a world-writable directory? I am sorry, > that's not an option. The stuff is already DoS-able enough, I am pretty > sure I don't want to open the door even wider. (Also what is this, > anyway? of all people, you as a security guy should know what bad an > idea that is...) The idea is not bad. Its the implementation that can be bad. Its possible to do this safely. And if you don't like this, then there are other ways to do it. You can add the user name to the file name and because we established above that pulseaudio won't delete the wrong kind of file, you are now able to determine which one to open. A benefit to doing this is that your code should be faster because strncmp() on the name and skipping the file is faster than doing a syscall which in turn does name resolution and then determines access permissions. Faster is good, right? :-) It might also be possible to unlink the file soon after creating it so that when the last reference is closed the file goes away automatically. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Friday, June 07, 2013 07:29:56 PM Matthew Garrett wrote: > On Fri, Jun 07, 2013 at 02:02:14PM -0400, Simo Sorce wrote: > > The point is that we are simply throwing ideas off the wall as an aid in > > finding a way to solve the issue for all. > > So why not add a mechanism to permit applications to indicate that > certain accesses they make should be ignored by audit? We've never needed an exception in the past. What I'm reporting is there is now a trend on the rise where apps are trying to open files that do not belong to them or open them not wanting the access time updated which attempts to bypass forensic time stamps. So far, the discussion has focused on pulseaudio. But what about the O_NOATIME issue? I wrote an article [1] for the hack in the box magazine a while back about using the audit system to look for application problems across the whole distribution at once. Its good at doing that. And like SE Linux, sometimes the fix is not to avoid auditing bad behaving apps, but to fix them. As for the O_NOATIME...cinnamon is the prime offender and neither it nor muffin have O_NOATIME anywhere in the code. So, its coming from a library. Anyone have any ideas? If we can fix that one at least we can make some progress. Thanks, -Steve [1] - http://magazine.hitb.org/issues/HITB-Ezine-Issue-005.pdf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Friday, June 07, 2013 08:42:09 PM Matthew Garrett wrote:
> On Fri, Jun 07, 2013 at 03:35:28PM -0400, Steve Grubb wrote:
> > So far, the discussion has focused on pulseaudio. But what about the
> > O_NOATIME issue?
>
> Without further analysis, it doesn't tell us much. Does the code attempt
> to open a file O_NOATIME and then fall back to trying it without?
It would appear so:
open("/usr/share/icons/gnome/48x48/status/dialog-password.png", O_RDONLY|
O_NOATIME) = -1 EPERM (Operation not permitted)
open("/usr/share/icons/gnome/48x48/status/dialog-password.png", O_RDONLY) = 12
read(12,
"\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\\0\0\\10\6\0\0\0W\2\371"..., 4096) =
2083
close(12) = 0
Which is a bad patterm. O_NOATIME requires CAP_FOWNER and I don't think
graphic programs are supposed to run as root/privileged. So, there seems to be
a misunderstanding of what O_NOATIME is for. It seems to be related to loading
icons. Is there a common library for that?
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Friday, June 07, 2013 05:02:41 PM Colin Walters wrote: > On Fri, 2013-06-07 at 22:14 +0200, Miloslav Trmač wrote: > > On Fri, Jun 7, 2013 at 10:05 PM, Colin Walters wrote: > > > On Fri, 2013-06-07 at 20:42 +0100, Matthew Garrett wrote: > > >> Without further analysis, it doesn't tell us much. Does the code > > >> attempt > > >> to open a file O_NOATIME and then fall back to trying it without? > > > > > > It's likely: > > > https://bugzilla.gnome.org/show_bug.cgi?id=680326 > > > > Is there any more rationale for the change available? > > http://lwn.net/Articles/244829/ > > > and the line in the sand between updatedb and thumbnail generation > > admittedly isn't all that clear.) > > Right. > > I guess we really want O_NOATIME_IF_POSSIBLE. Although I wonder if > there's any reason not to just silently ignore O_NOATIME if it's not > permitted, rather than force apps to double open(). Hmm...sounds like kernel change. But in the meantime, most of the offenders I see seem to have something to do with loading icons: name=/usr/share/icons/gnome/16x16/mimetypes/x-office-document.png 30 name=/etc/pki/tls/certs/localhost.crt 25 name=/usr/share/icons/hicolor/48x48/apps/firefox.png 11 name=/usr/share/icons/hicolor/22x22/apps/firefox.png 10 name=/usr/share/icons/hicolor/24x24/apps/firefox.png 9 name=/usr/share/icons/hicolor/32x32/apps/firefox.png 9 name=/usr/share/icons/gnome/16x16/actions/window-close.png 9 name=/usr/share/icons/hicolor/256x256/apps/firefox.png 8 name=/usr/share/icons/hicolor/16x16/apps/firefox.png 8 name=/usr/share/icons/gnome/24x24/actions/go-up.png 7 name=/usr/share/icons/gnome/24x24/actions/go-down.png 7 name=/usr/share/icons/gnome/24x24/places/folder.png 7 I think we can assume root owns the icons which mean calls with NOATIME as a normal user session will fail. Maybe the call that opens the icon can be switched to a regular open? Thanks, Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Saturday, June 08, 2013 06:33:11 AM Matthew Garrett wrote: > On Fri, Jun 07, 2013 at 07:03:24PM -0600, Stephen John Smoogen wrote: > > On 7 June 2013 12:29, Matthew Garrett wrote: > > > So why not add a mechanism to permit applications to indicate that > > > certain accesses they make should be ignored by audit? > > > > Just so people know, this is like one of the the oldest auditing argument > > in the world. I have had programmers say that since the 1990's. [The > > standard counter story is that user program X says "don't audit anything I > > do in /etc." The programmer counters with adding in a black list of > > directories that can't be audited, this gets countered by something else > > and eventually you have a process where programs that have a GPG signature > > that has been accepted as valid by the audit program can say which of the > > white listed files it wants opened without audit are dealt with... and > > then > > some other programmer comes in and shows the 20,000 lines of need to be > > audited code replaces 40 lines of C code in the programs that were causing > > the problem.] > > Well, http://www.stigviewer.com/check/V-29067 implies that filtering of > audit records is a reasonable thing to do. What this requirement is talking about is that we must provide something like ausearch. OK, we do that. What I am telling you is that the OS has changed in a bad way in the last year or two. It has _never_ been this noisy for auditing. Look at this: # aureport --start this-week --key --summary Key Summary Report === total key === 73520 access 562 module-load 149 module-unload 135 bypass 132 system-locale 132 container-config 113 time-change 110 identity 100 data-injection 88 container-create 88 export 58 register-injection 44 code-injection 29 power-abuse 22 modules-del 22 modules-add 22 MAC-policy The bad access events dominate the event log. > I have no expectation that arbitrary user applications should be able to do > whatever they want without leaving an audit trail, but I don't see what that > has to do with system applications. Root has the ability to modify the > selinux policy, so root (and packages installed by root) should have the > ability to modify the set of behaviours that trigger audit records. Its not quite like this. What I need is the OS to be well behaved under normal conditions so that when problems come along they are easily spotted. Fedora has been a fairly well behaved OS over the years. I have had to get a few apps fixed in the past and the maintainers have always been accommodating. But this time I am finding we have a serious problem worse than in the past. Thanks, -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Saturday, June 08, 2013 06:36:38 AM Matthew Garrett wrote: > On Fri, Jun 07, 2013 at 05:24:30PM -0400, Steve Grubb wrote: > > Hmm...sounds like kernel change. But in the meantime, most of the > > offenders I see seem to have something to do with loading icons > > Sounds like code that doesn't differentiate between files that are in > user-local directories and system-global directories. That's something > that could presumably be fixed, but it seems like a bunch of effort. From the code I saw previously, it seems like just changing the function being called to the variant without noatime in its name. The comments in the code Colin pointed to say this: * gs_file_read_noatime: * @file: a #GFile * @cancellable: a #GCancellable * @error: a #GError * * Like g_file_read(), but try to avoid updating the file's * access time. This should be used by background scanning * components such as search indexers, antivirus programs, etc. And evince, firefox, or openoffice are not any of those ^^. :-) > Other than a heuristic based on whether a path is in the user's home > directory or not, the only way to avoid this is to stat before opening - > and that's obviously prone to failure. Does opening with noatime really make a measurable difference (assuming it worked)? I suspect not since what we have now is 2 syscalls. It would probably be faster to load icons without trying to set NOATIME. Thanks, -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Saturday, June 08, 2013 09:34:22 AM Steve Grubb wrote:
> Does opening with noatime really make a measurable difference (assuming it
> worked)? I suspect not since what we have now is 2 syscalls. It would
> probably be faster to load icons without trying to set NOATIME.
Answering my own question
#include
#define __USE_GNU
#include
#include
#include
void noatime(void)
{
int fd = open("/usr/share/icons/hicolor/48x48/apps/firefox.png",
O_RDONLY|O_NOATIME);
if (fd>=0)
close(fd);
else {
fd = open("/usr/share/icons/hicolor/48x48/apps/firefox.png",
O_RDONLY);
if (fd>=0)
close(fd);
}
}
void atime(void)
{
int fd = open("/usr/share/icons/hicolor/48x48/apps/firefox.png",
O_RDONLY);
if (fd>=0)
close(fd);
}
int main(int argc, char *argv[])
{
int i, mode=0;
if (argc == 2 && strcmp("noatime", argv[1]) == 0)
mode = 1;
for (i=0; i<5000; i++) {
if (mode)
noatime();
else
atime();
}
return 0;
}
As a normal user:
$ time ./test noatime
real0m12.645s
user0m0.003s
sys 0m0.159s
$ time ./test atime
real0m0.019s
user0m0.002s
sys 0m0.016s
Way faster doing a normal open. As root:
# time ./test noatime
real0m0.019s
user0m0.000s
sys 0m0.019s
# time ./test atime
real0m0.019s
user0m0.001s
sys 0m0.017s
No real difference between them.
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Saturday, June 08, 2013 09:57:03 AM Doug Ledford wrote: > Bad test. The first run took the hit for getting the file info into > page cache, after that, everything was run from cache and you got the > second result above and the results below. You have to make sure that > from run to run the cache state of the file in question is identical. Try it yourself. :-) I know what you are saying and run the test probably 8 times before posting results. I also have the audit rule loaded...so removing it: [sgrubb@x2 noatime]$ time ./test noatime real0m0.031s user0m0.006s sys 0m0.024s [sgrubb@x2 noatime]$ time ./test noatime real0m0.033s user0m0.002s sys 0m0.032s [sgrubb@x2 noatime]$ time ./test noatime real0m0.036s user0m0.002s sys 0m0.031s [sgrubb@x2 noatime]$ time ./test atime real0m0.023s user0m0.001s sys 0m0.021s [sgrubb@x2 noatime]$ time ./test atime real0m0.022s user0m0.003s sys 0m0.019s [sgrubb@x2 noatime]$ time ./test atime real0m0.023s user0m0.002s sys 0m0.019s Without the audit rules, it is faster. But again opening with noatime attempted is measurably slower. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Saturday, June 08, 2013 10:13:45 AM Doug Ledford wrote: > Yes, but none of these results show the .12s time that your first > noatime test run showed in your original post. If you are now saying > that atime is faster than noatime by about .005 to .010s, then these > results seem to show that. But your original post was from .019 to .12, > or a difference of .10+s. That was cache load time, not just the > syscall difference. I chalk that up to the audit system. The audit system tries real hard to stay out of the way since the vast majority of syscalls are not interesting. But if you trigger an event, it has to get recorded in gory detail and that takes time. (The first run did trigger 5000 audit events, the others didn't.) This is another reason (but not the main reason) we need to try to avoid triggering events in a normally operating machine. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad file access on the rise
On Sunday, June 09, 2013 05:56:42 AM Matthew Garrett wrote: > On Sat, Jun 08, 2013 at 08:28:48PM -0400, Doug Ledford wrote: > > On 06/08/2013 02:35 PM, Adam Williamson wrote: > > > Well, you're defining something as 'bad behaviour' fairly arbitrarily - > > > or at least controversially: not everyone agrees with your definition. > > > > Speaking as a former sysadmin responsible for intrusion detection, this > > is not a controversial definition at all (namely that anything that > > creates audit events without a reasonably just cause is 'bad behavior'). > > It is the only sane definition of 'bad behavior'. Anything that makes > > an admin go chasing ghosts for no good reason is most definitely 'bad > > behavior', and every single audit event on a system must be identifiable > > by the admins before you know your system is secure. Thanks Doug. I don't think I could have said it better myself. These events also consume space. Each one of these occupy about 600 bytes. But when you multiply that by the number I gave you yesterday for a week of these events, it gets large. Because I work on the audit system, I have a 100Mb dedicated partition for audit logs. Until recently, that would hold about a year's worth of events. The audit rules have not changed in maybe 4 years. When I run aureport --log today, my logs only go back to May 30 of this year. That's how big of an impact this is. As to the reason why I didn't bring this up earlier, upstream broke the audit system on the 3.7 kernel and it wasn't fixed until the 3.9.4 kernel. > I don't think anyone wants these accesses to generate audit records. The > question is whether the right way to fix that is to avoid those accesses > in the first place or to provide a mechanism so that legitimate accesses > don't generate audit records. There isn't a mechanism to allow these to slip through. Over the years I have come to realize that the audit system can be a great resource for debugging user space. It was sitting through one of Dave Jones' why userspace sucks lectures and afterwards pouring through audit logs that I saw that we can find some of these problems. If part of the goals when writing software is correctness and efficiency, then wouldn't failing syscalls be of interest? Not just in the case of EPERM, but also for example EINVAL? Why would anyone write software that is incorrect enough the OS spits it back as EINVAL? I think its because they didn't know and in some cases it was written on another OS that accepts that particular input. To that point, you can load these two rules: auditctl -a exit,never -F arch=b64 -S rt_sigreturn auditctl -a exit,always -S all -F exit=-EINVAL -k einval-test and then use the computer for a while. To see what you get: # ausearch --start today -k einval -m SYSCALL --raw | aureport -x --summary Executable Summary Report = total file = 165 /usr/libexec/mysqld 149 /usr/bin/man 105 /usr/lib/udisks2/udisksd 74 /usr/sbin/libvirtd 16 /usr/lib/systemd/systemd-udevd 8 /usr/lib64/firefox/firefox 5 /usr/bin/python2.7 2 /usr/sbin/modem-manager 2 /usr/sbin/NetworkManager 2 /usr/bin/gnome-terminal 1 /usr/bin/qemu-kvm 1 /usr/bin/knotify4 1 /usr/bin/xchat Who knew all these programs were making invalid syscalls? Which syscalls are we having a problem with? # ausearch --start today -k einval -m SYSCALL --raw | aureport -i --syscall -- summary Syscall Summary Report == total syscall == 320 readlink 149 munmap 74 rt_sigaction 9 ioctl I'll leave it here for anyone curious enough to dig out the details of how each syscall is wrong. But its my belief that these are not intentionally written to fail and people didn't know they were issuing syscalls that will never work. The audit system can be used to find software problems so the system operates more efficiently. Thanks, -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retiring Prelude IDS
Hello, I am going to retire the Prelude Intrusion Detections System in F20. Upstream has been dead for over 3 years. The only packages that I know that link against it is pads, audit, and suricata. I own all 3 of those packages, so this should mostly be a FYI for everyone here. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F19 upgrade pulls in a lot of i686 packages
Hi, Did anyone notice all the i686 packages that get pulled in if you try to upgrade from F18? My system has no i686 packages on it today. But when I try to upgrade it starts getting i686 dependencies pulled in. It starts like this: ---> Package mesa-libEGL.x86_64 0:9.2-0.7.20130528.fc18 will be updated ---> Package mesa-libEGL.x86_64 0:9.2-0.12.20130610.fc19 will be an update ---> Package mesa-libEGL-devel.i686 0:9.2-0.12.20130610.fc19 will be obsoleting --> Processing Dependency: libEGL.so.1 for package: mesa-libEGL-devel-9.2-0.12.20130610.fc19.i686 ---> Package mesa-libEGL-devel.x86_64 0:9.2-0.12.20130610.fc19 will be obsoleting From that it goes into: ---> Package mesa-libEGL.i686 0:9.2-0.12.20130610.fc19 will be installed --> Processing Dependency: libxcb.so.1 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libxcb-xfixes.so.0 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libxcb-shape.so.0 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libxcb-render.so.0 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libxcb-dri2.so.0 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libwayland-server.so.0 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libwayland-client.so.0 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libudev.so.1(LIBUDEV_183) for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libudev.so.1 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libselinux.so.1 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libpthread.so.0(GLIBC_2.0) for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libpthread.so.0 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libglapi.so.0 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libgbm.so.1 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libdrm.so.2 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libdl.so.2(GLIBC_2.1) for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libdl.so.2(GLIBC_2.0) for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libdl.so.2 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libc.so.6(GLIBC_2.4) for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libX11.so.6 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 --> Processing Dependency: libX11-xcb.so.1 for package: mesa-libEGL-9.2-0.12.20130610.fc19.i686 and then later dozens more get pulled in. Should looking for this be part of future release criteria? -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F19 upgrade pulls in a lot of i686 packages
On Saturday, June 29, 2013 06:15:49 PM Michael Schwendt wrote: > On Sat, 29 Jun 2013 10:34:09 -0400, Steve Grubb wrote: > > Did anyone notice all the i686 packages that get pulled in if you try to > > upgrade from F18? My system has no i686 packages on it today. But > > when I try to upgrade it starts getting i686 dependencies pulled in. It > > starts like this: > > > > ---> Package mesa-libEGL.x86_64 0:9.2-0.7.20130528.fc18 will be updated > > ---> Package mesa-libEGL.x86_64 0:9.2-0.12.20130610.fc19 will be an update > > ---> Package mesa-libEGL-devel.i686 0:9.2-0.12.20130610.fc19 will be > > obsoleting --> Processing Dependency: libEGL.so.1 for package: > > mesa-libEGL-devel-9.2-0.12.20130610.fc19.i686 ---> Package > > mesa-libEGL-devel.x86_64 0:9.2-0.12.20130610.fc19 will be obsoleting > That's the dangerous noarch -> arch switch. khrplatform-devel.noarch > is an old subpackage from "mesa". > > Package mesa-libEGL-devel for both i686 and x86_64 Obsoletes and Provides > khrplatform-devel: > http://koji.fedoraproject.org/koji/buildinfo?buildID=427384 Yes, this is exactly the problem. I suppose F19 instructions might need to be updated to say delete the package using "rpm -e --nodeps" and then it should get pulled back in by dependency without pulling in all the i686 stuff. Doing that let me get to the next problem. Someone else asked how I was doing the upgrade...using this: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum Do we really still need to run grub2-install as the instructions say in preparing for reboot? It errors out with some warning about ext2 file systems not being supported even though its ext3. Then reboot fails saying error: symbol 'grub_term_highlight_color' not found. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with static code analysis in Fedora
On Wednesday, December 12, 2012 01:00:36 AM Paulo César Pereira de Andrade wrote: > > A while back I ran my static checker on all of the Python extension > > > > modules in Fedora 17: > > http://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts > > > > I wrote various scripts to build the packages in a mock environment that > > injects my checker into gcc, then wrote various scripts to triage the > > results. I then filed bugs by hand for the most important results, > > writing some more scripts along the way to make the process easier. > > > > This led to some valuable bug fixes, but the mechanism for running the > > analysis was very ad hoc and doesn't scale. > > I think it could be useful at least as a generic tool where one would > just do something like: > make CC=gcc-with-python-plugin > like some time ago one could run > make CC=cgcc > to see what sparse would tell. Or maybe think of it as a tool like > rpmlint. I wrote a program, fake-make which collects everything so that programs like cppcheck can be run with correct defines, paths, and files. Instructions are here: http://people.redhat.com/sgrubb/swa/cwe/index.html That said, what's really needed is every analyzer to output messages with something in common so that results can be compared. That something in common is CWE (Common Weakness Enumeration). I was working on a mapping for cppcheck to CWE so that it could be correlated with other tools. the advantage of CWE is that its also married to CAPEC (Common Attack Pattern enumeration and classification). This mapping shows some possible ways that the bug being found could be exploited depending on other mitigating factors. So, what would be nice is to figure out how to get all the static analyzers and compilers outputting CWE information. Then define a common format so that correlation tools can be built. If several tools report the same issue at the same line, then its probably not a false positive and someone should look at it. But at the same time, not all bugs are created equal. A buffer overflow is a worse problem than unchecked return code (unless its setuid(2)). There is a scoring framework, CWSS (Common Weakness Scoring System) that can be used to rank bugs so they can be prioritized. It also takes into account the effect of the bug withon the program its found in. For example, buffer overflow in network app or daemon is more critical that same issue in a program run by authenticated users such as "ps". Don't get me wrong, there are corners cases...but some heuristic has to be used and decisions have to be made. So.. this would be my advice...try to follow these standards. Its all part of a larger project to track weaknesses, combine with configuration information, and network IDS systems for real time situational awareness. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Virtio RNG
On Friday, February 01, 2013 04:39:17 PM Bill Nottingham wrote: > Given FIPS paranoia about RNG sources, does this have knock-on effects in > the FIPS compliance of guests depending on how it's fed in the host? There is no FIPS problem here. Its more of a common criteria issue. But here is a little back story on it. The UK created this standard: http://www.cesg.gov.uk/publications/Documents/CPA_Security_Characteristic_for_Server_Virtualisation_v1.21.pdf This is the relevant section: "DEP.5.M249: Confirm the entropy available to the network encryption is sufficient. This mitigation is required to counter the exploitation of any loss of entropy in the Guest OS leading to insecure network encryption. At Foundation Grade the deployment is required to use an external entropy source, or use the NIST tests on the raw entropy data to confirm that the entropy being produced within the VM is sufficient. In this context, 'external' means that the entropy was generated from some reliable source of entropy outside the VM (and possibly outside the platform altogether). This includes solutions where the network encryption is terminated outside the VM (for example, using a TLS concentrator). The issue is that the usual sources of entropy on a physical machine (such as disk timings) may not provide the same amount of entropy once virtualised, and the loss of entropy will weaken encryption that relies on it." NIAP picked up on this and its now required. The fear is that virtualization is done based on a scheduler and the delays and timings that are used by the kernel to mine entropy from hardware would have artifacts in it from this scheduler. The fear is that an attacker could use this information to guess what entropy is in the pool by modelling it carefully. Whether or not this is a problem in practice is still being debated. Its just easy to avoid by doing a pass-thru than doing a study and arguing the fear is irrational. It very well may be possible that guests have low quality entropy and that would be bad for generating ssh keys. And for the record...random numbers are not entropy. They have entropy but they are not the same. The reason is because the real entropy is conditioned with a hash function before it hits user space. And in the case of urandom, it may generate its own numbers for a while before getting reseeded with entropy. The upshot of which is you have random numbers, but the entropy content is lower but its still sufficient for cryptographic purposes. Hope this helps... -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bodhi issue
Hello, Yesterday I built a security update for the suricata package, 3.2.1-1: https://koji.fedoraproject.org/koji/packageinfo?packageID=10021 Any time I try to create the bodhi new release, it finds an older build, 3.2-1. Typing the version in causes it to say it can't find any package that matches the query. How should I go about getting this security update out? Thanks, -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
